Что не стоит делать с php.ini


Что не стоит делать с php.ini

Сообщение surfer »

Данный материал не претендует на истину в последней инстанции, но стремится показать, что исходить надо из понятия здравого смысла.
Здесь я хочу написать о том, как все-таки настроить вывод ошибок скрипта?

Еще Генри Форд в свое время говорил (тут будет моя интерпретация его слов, но с сохранением смысла):
Если что-то можно сделать стоя или сидя, сделай это сидя,
если что-то можно сделать сидя или лежа, сделай это лежа.


Тема конфигурационного файла php.ini обсуждалась не раз, решил и я затронуть эту тему, открою секрет публикаций будет несколько :beer:
Кто пользуется виртуальным хостингом она не будет полезна, но если в вашем расположении выделенный сервер, то читай дальше.

Параметры конфигурации php имеют 4 уровня:
PHP_INI_USER - Значение может быть установлено в пользовательских скриптах (с помощью ini_set())
PHP_INI_PERDIR - Значение может быть установлено в php.ini, .htaccess или httpd.conf
PHP_INI_SYSTEM - Значение может быть установлено в php.ini или httpd.conf
PHP_INI_ALL - Значение может быть установлено отовсюду

А теперь давайте включим здравый смысл и вспомним Генри Форда

Зачем менять глобальные настройки для всего сервера, если мы можем это сделать на уровне скрипта? Правильно!
Во-первых это безопасность, в принципе и во-вторых и в-третьих, продолжать можно бесконечно долго.
Что дает безопасность. в данном случае6? Изолированность проектов. Наверняка у вас на сервере крутится больше одного проекта, и возможно только один используется для тестирования и отладки. Так зачем вам показывать ошибки для всех проектов. Глупо, не правда ли?

Реальный пример:

Есть очень известный сайт, существует с начала века, недавно ночью я зашел на него и обнаружил:
Код: Выделить всё
Notice: unserialize(): Error at offset 0 of 62532 bytes in /home/*********.ru/www/objects/memcached/memcached.inc.php on line 29 Notice: Undefined index: content in /home/*********.ru/www/objects/templates/templates.inc.php on line 413 Notice: Undefined index: params in /home/*********.ru/www/objects/templates/templates.inc.php on line 414 Fatal error: Method TemplateParam::__toString() must not throw an exception, caught Error: Call to a member function get_data() on null in /home/*********.ru/www/user/manager.inc.php on line 0

через время перезагрузил страницу и вылезло вот что:
Код: Выделить всё
Warning: mysqli::__construct(): (HY000/1040): Too many connections in /home/*********.ru/www/objects/memcached/memcached.inc.php on line 14 Warning: mysqli::real_escape_string(): Couldn't fetch mysqli in /home/*********.ru/www/objects/memcached/memcached.inc.php on line 19 Warning: mysqli::query(): Couldn't fetch mysqli in /home/*********.ru/www/objects/memcached/memcached.inc.php on line 21 Notice: Trying to get property of non-object in /home/*********.ru/www/objects/memcached/memcached.inc.php on line 22 Warning: mysqli::__construct(): (HY000/1040): Too many connections in /home/*********.ru/www/objects/database/database.inc.php on line 265 Can't connect to DB

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

Поэтому я рекомендую не трогать директиву, отвечающую за вывод ошибок, не зря по умолчанию разработчики отключили вывод ошибок в браузер, вспоминаем Генри Форда.
Если на этапе разработке это лучше сделать функциями самого php, все зависит от архитектуры вашего скрипта, если все идет через index.php, то в его начале вот такой код:
Код: Выделить всё
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL);

Либо сделай функцию или класс/метод и вызывай по необходимости. Этого будет достаточно.

При запуске в скрипта в продакшен можете сделать логирование и все класть туда, можете даже сделать, чтобы сообщения об ошибке сразу приходило вам на почту.

Предвосхищая возражения, я могу сказать только одно. Если бы да кабы не позволяет вам формировать мышление разработчика.

ЗЫ. Без надобности не лезь в конфигурационные файлы сервера.


За это сообщение автора surfer поблагодарили: 2
birds, k0ttee
Аватара пользователя
surfer

 
Группа: Специалист ruSEO
Сообщения: 1083
Зарегистрирован: 26 июл 2012
Средств на руках: 196.78
Статус: backend
Re: Что не стоит делать с php.ini

Сообщение k0ttee »

Таки была моя старая тема, где очень простой выводи ошибок "только для авторизованного себя". Ни единой ошибки не было! :lol:
Сбор на вискас
btc: 3Hq7X9CosVftRFPqWis1Dkk5MdtM1u6jj9
ltc: LTsZ8f261j5qS5QUjn7ihzr37hziTvXeA4
Аватара пользователя
k0ttee

 
Группа: Специалист ruSEO
Сообщения: 12039
Рефералы: 2
Зарегистрирован: 02 май 2014
Средств на руках: 6.00
Спонсор
 
Re: Что не стоит делать с php.ini

Сообщение surfer »

k0ttee писал(а):Таки была моя старая тема, где очень простой выводи ошибок "только для авторизованного себя". Ни единой ошибки не было! :lol:

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

А не было ошибок, наверное потому что это не работает?
Аватара пользователя
surfer

 
Группа: Специалист ruSEO
Сообщения: 1083
Зарегистрирован: 26 июл 2012
Средств на руках: 196.78
Статус: backend
Re: Что не стоит делать с php.ini

Сообщение prolisk »

surfer писал(а):ЗЫ. Без надобности не лезь в конфигурационные файлы сервера.

самое верное замечания, тем более, ТЕМ более, если не виртуальный хостинг, а свой сервер...Ведь его и положить можно...
Аватара пользователя
prolisk

 
Группа: Супермодераторы
Сообщения: 14501
Рефералы: 5
Зарегистрирован: 07 янв 2011
Откуда: С той стороны экрана.
Средств на руках: 0.65
Статус: django
Re: Что не стоит делать с php.ini

Сообщение k0ttee »

во-первых зачем так усложнять себе жизнь?

Из этого
Код: Выделить всё
ini_set('error_reporting', E_ALL);

Сделать это
Код: Выделить всё
if( /* тут определение авторизован пользователь или нет для вашей cms */ )
   {
   function dump_errors($errno,$errstr,$errfile,$errline,$errcontext) //авторизованному показываем ошибки (по своим условиям)
      {
      //условия задаем сюда
      }
      set_error_handler('dump_errors');
   }
else //иначе
   {
   error_reporting(0); //остальным ошибки не покажу
   }

Усложняет жизнь? :blink:

Если обертка if усложняет жизнь, то мне ну очень тяжело живется. :-D А комментарии в коде - усложняют больше всего.

во-вторых о какой cms идет речь, ибо приведенный пример вряд ли будет работать в большинстве движков?

Конструкция языка может не работать в движках? :blink: Тогда нахер движки.
Код: Выделить всё
if( ){ }else{ }


А не было ошибок, наверное потому что это не работает?

Ошибок не было по тому что код самописный, а вот код сапы сыпал warning'ами. :-P
Апеллирую в здравому смыслу. Зачем?

Вы свой код пишите, или шлепаете на движке?
Сбор на вискас
btc: 3Hq7X9CosVftRFPqWis1Dkk5MdtM1u6jj9
ltc: LTsZ8f261j5qS5QUjn7ihzr37hziTvXeA4
Аватара пользователя
k0ttee

 
Группа: Специалист ruSEO
Сообщения: 12039
Рефералы: 2
Зарегистрирован: 02 май 2014
Средств на руках: 6.00

Вернуться в Железо и софт

 


  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23