Евгений Крупченко

Евгений Крупченко
Рейтинг
165
Регистрация
27.09.2003
Интересы
хостинг без тормозов
SeVlad #:
Жесть.. просто жесть.

Это правда жизни большинства сайтов на дешевых shared хостах.

Я не обобщаю это на всех и ни на что своё уж тем более не проецирую. Всего лишь предложил один из очевидных выходов в данной ситуации, зачем на все так агрессивно реагировать :)

Если ТС в силах сменить шаблон на тот, где не будет ошибок... то зачем вообще было тут что-либо спрашивать спрашивается? Надо было первым делом это и сделать. Я ведь предположил, что это непосильная задача.

И даже не посылал его "В конфиге вебсерера/хтасесее", понимая что это еще менее реальной задачей окажется, а сказал что лучше обратиться к хостеру.


[offtopic]

SeVlad, я уже с большой буквы пишу и все равно какая-то ненависть ко всему человечеству чувствуется. Ну да ладно... Уверен, это все из-за отсутствия велосипеда 😎 - предложение бесплатного велосипеда до конца года в силе если что. Я ж не просто так, не безосновательно считаю свои велосипеды хорошими (за свою цену), знаю что колеса должны быть не квадратными, не треугольными, а именно круглыми. И подозреваю, что максимум что вам доводилось водить это с овальными колесами. От того и раздраженность и нетерпимость к окружающим. Какой-то перманентный ПМС.

Мне это напоминает серию:

https://internetkomfort.io.ua/v85f6b9eaa6d3b5e48b02313e54d71b2a

Советую переступить гордость и посмотреть 👍

[/offtopic]

Я лишь хотел донести мысль, что есть (и очень много) сайтов/владельцев/ситуаций когда что-либо исправлять это вообще не про них, это практически не реально.

Не потому что это сложно сделать, а потому что владелец просто не будет тратить на это время, владелец сам не разбирается и не будет изучать ничего нового, владельцу сайт не на столько дорог, чтоб платить кому-то за исправления. И даже заняться найти актуальную замену - тоже может оказаться непосильной задачей для владельца. Уж поверьте опыту, какие только клиенты не встречаются. Даже просто создать в корне файлик для яндекс верификации - просто черная магия, требующая обращения за платной услугой к "программистам". О чем вы тут, о каком исправлении ошибок говорите, какой там "админ" что-то когда-то увидит, я вас умоляю 😉

А потому вариант "чего не видно, того и нет" тут более чем применим.

Как именно - не суть важно, не надо придираться к последовательности.


Дыры? Опять же, если взломают (вполне может быть что давно сделали, просто владелец не в курсе 😑 и прекрасно живет с этим) то невелика потеря.

Даже если исправить все те warning и deprecated, возможные дыры не перестанут там существовать... а обновить/заменить как уже сказано скорей всего не вариант, иначе бы и вопросов таких никто не задавал.


В общем я так и не понял что конструктивного вы предлагаете. Возьмитесь да почините/обновите/замените ему бесплатно. Не?

Так что в итоге ТС'у делать предлагаете? 😐

Вам же прямо сказано - "как её исправить незнаю", а значит он точно не будет ничего исправлять.

Нет, можно конечно сколько угодно умничать и в целом все правильно - ошибки надо не прятать, а исправлять, но... серьезно, если обновлений от автора скриптов (шаблонов или что там...) просто нет и не будет, никто же не пойдет ковыряться вникать в чужой код. Верней тот кто сможет, то в принципе не пользуется чужими поделками и уж тем более не сидит в конце 2020 на php 5.3.

Потому какой выход реальный? Никто тут конечно не видел что там за сайт, но с 99% можно предположить что никакой особой ценности не представляющий. А потому просто спрятать warning'и и забить на все - нормальное решение в данной ситуации. Либо заплатить кому-то, чтоб поковырялся и исправил... но опять же, мы не знаем никаких подробностей, может это будет стоить в 5 раз дороже, чем весь тот сайт стоит целиком.


И добавлю еще что display_errors=off это не только нормально, но и необходимо, если это продакшн сайт, а не что-то без траффика для экспериментов своих.

Ошибки пусть пишутся в логи, а на сайтах отображать их нельзя.  Это не красиво, это не профессионально и может быть даже опасно в случае если в этой ошибке высветится что-то, чего посторонним знать не нужно.

Вы хоть раз видели какие-то ошибки скриптов на чем-то более-менее серьезном? Ошибки у всех случаются, у того же гугла и авито не раз видел, но это были именно правильно оформленные перехваченные ошибки, а не тупо ошибка в таком-то скрипте, такой-то строке.

Это НЕ ошибки. Если кроме этих надписей ничего не сломалось больше, то самое простое - просто скрываем в настройках php их отображение:

error_reporting=E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_WARNING

(как сделать - хостеру пишите если не в курсе)

Или вообще все отображение ошибок выключаем:

display_errors=off

Просто чел очень хотел чтоб все поверили, что он из США, а не Архангельска.

Тот openapi-sandbox.kucoin.com выдает вам ответ 401 Unauthorized

И Invalid KC-API-SIGN - что бы это ни значило.

Т.е. со скриптом все ок, но не ок со взаимодействием с тем сторонним хостом. Уж не знаю что и как там должно быть.

Во-первых домен ip-123-456-789.eu свободен, а значит никакого поддомена ns123456.ip-123-456-789.eu быть не может.


Если у вас по нему что-то там открывается, то это уже вопрос в совершенно другой плоскости.


Но если в общих чертах, то всегда надо делать основной "заглушку". Чтоб при обращении по ip (или любому привязанному к этому ip домену) открывался не первый сайт из конфига, а эта заглушка.

<fieldset>
<legend>Capture</legend>
</fieldset>

Ну про злоупотребления - это скорей редкость, чем постоянно так происходит. И да, ограничить память можно уровнем выше, пусть хоть сколько угодно ставят memory_limit.

В любом случае, всем же не навязываю, у вас своя политика, у меня своя - чем меньше ограничений, тем лучше для конечного клиента. А с теми редкими случаями нагления лучше решать вопрос индивидуально, чем из-за них резать все подряд всем.


Да, auth_socket и по-сути да, авторизация конечно никуда не пропадает, а просто чуть упрощается. И да... возможно насчет какого-то ускорения это я загнул 😀

Просто была мысль попробовать, но застопорилось на проблеме скриптов типа phpmyadmin в открытом доступе.

Основная идея скорей была в упрощении. Т.е. добавляя новую базу, нужно бы было от пользователя только имя базы и все. Момент с логин/паролями вообще упразднить. И чтоб в скриптах своих логин/пароли на базу они могли использовать любые. К примеру перенес с другого хоста и сразу заработало, без правки конфигов.

Суть в том, что если что-то (например php скрипт) уже запущен от имени какого-то пользователя, то смысла еще авторизоваться по паролю к mysql нет никакого. Если это скрипт злоумышленника, то также не составит труда этим скриптом открыть любой файл конфига и там взять этот пароль.

Авторизация нужна если доступ к сокету mysql есть у всех (в случае одной общей mysql например) или, что еще хуже, mysql открыта портом в интернет.

А когда у нас все заперто в рамках одного пользователя (mysql, apache/php, все файлы), то эта доп. авторизация mysql вообще не несет ценности. Самое главное это не запускать опасный код из под себя. А если уж запустил, то все... никакая авторизация не спасет.

locoye1191 #:
Украинцы делают хостинг и сразу сливаются. Больше года не хватает. Это уже 3 хостинг который сделал так. Похоже у них это нормально.

Попросил бы не обобщать.

Вы сами умудрились заплатить непойми кому, а теперь все виноваты?

Самое первое что нужно смотреть это кто такие, где находятся, офф регистрацию проверять и т.д.

Вот у вас претензия образовалась к ним и дальше что? Кому предъявлять? Нужно было об этом думать ДО оплаты.

Там где анонимность, там высокий % жулья.

Всего: 516