Возможно кому-нибудь пригодится небольшая заготовка для обращения в техподдержку хостинга от имени владельца интернет магазина.
Добрый день служба поддержки НАЗВАНИЕ_ХОСТЕРА
Мне необходимо изменить конфигурационный параметр max_input_vars, который сейчас имеет дефолтное значение 1000. В ранних версиях PHP изменение данного параметра можно было сделать через файл .user.ini в корне аккаунта. Однако в версии 5.4.32, на которой работает мой сайт, данный параметр отнесен к режиму PHP_INI_PERDIR (значение может быть установлено в php.ini, .htaccess или httpd.conf). Доступа к php.ini у меня нет, изменение в .htaccess скорее всего делаю неправильно, так как не приводит к должному эффекту.
Как увеличить параметр, например чтобы max_input_vars = 12000 ?
Иначе у меня в скрипте не обрабатываются формы редактирования товаров, содержащие большое количество полей (множество подвидов товара на одной странице формы, цен, фотографий товара, параметров товара и т.п.). При попытке запостить такую форму, она просто обрывается и изменения не сохраняются. Небольшие по объему формы сохраняются успешно.
Как это сделать в Impera CMS
Как увеличить параметр, например чтобы max_input_vars = 12000 ?
Иначе у меня в скрипте не обрабатываются формы редактирования товаров, содержащие большое количество полей (множество подвидов товара на одной странице формы, цен, фотографий товара, параметров товара и т.п.). При попытке запостить такую форму, она просто обрывается и изменения не сохраняются. Небольшие по объему формы сохраняются успешно.
Ответ службы поддержки
Добрый день
Данный параметр Вы можете поменять в файле .htaccess строкой, например в начале файла:
php_value max_input_vars 12000
И в выводе phpinfo проверить внеслось ли изменение этого параметра.
Добрый день
Данный параметр Вы можете поменять в файле .htaccess строкой, например в начале файла:
php_value max_input_vars 12000
И в выводе phpinfo проверить внеслось ли изменение этого параметра.
Как это сделать в Impera CMS
- админпанель, страница разное -> Корневой .htaccess - здесь добавляем указанную строку
- админпанель, страница утилиты -> Информация о PHP - здесь смотрим, изменился ли параметр
Вообще говоря проблема может быть решена 3 способами (от простейших к сложным):
- вы или хостер увеличивает параметр сам
-
на страницу с раздутой формой добавляется ajax-примочка, собирающая поля формы, сериализует их в строку (например аналогично JSON), делает клон формы без полей, добавляет туда поле-строку и постит клонированную форму
- на серверной стороне сайта в начальную точку скрипта придется добавить php-код, который выполняет обратные действия над переменной $_POST - разобрать принятую строку в набор полей
-
переделать шаблон (tpl-файл) раздутой формы так, чтобы все поля формы, не являющиеся массивами, были инкапсулированы в элементы дополнительного транспортного массива, числом не более max_input_vars в каждом элементе
- на серверной стороне сайта в начальную точку скрипта придется добавить php-код, который выполняет обратные действия над переменной $_POST - декапсуляция полей в общий набор и удаление транспортного массива
Что такое max_input_vars
Это конфигурационный параметр, введенный с целью уменьшения вероятности атак, рассчитывающих на уязвимости скриптов к избыточному количеству полей в присланной форме, либо атак на поглощение процессорного времени сервера, когда интерпретатор PHP пытается разобрать злонамеренно сформированную форму с огромным количеством полей, хеши имен которых совпадают.
Механизм атаки на поглощение времени
Представим, что запостили форму с миллионом полей (для простоты, считаем методом POST). Если не введен параметр лимита, разбор этих полей по именам и занос их в переменную $_POST займет какое-то время. Чтобы ускорить разбор, интерпретатор оперирует не именами полей, так как они могут иметь разную длину, а хешами имен - в данном контексте они подобны индексам массива. При специально подобранных именах полей, то есть когда хеши некоторых полей совпадают, можно вынудить интерпретатор пробегать по индексному пространству заново, экспоненциально растрачивая время.
Механизм атаки на уязвимость к избытку
Предположим, скрипт обрабатывает в ожидаемой форме всего два поля name и sum. Как подменить первое поле, чтобы подменяющее (избыточное) поле не вызвало у проверяющего подозрение своей одноименностью с первым полем? Нужно чтобы хеш имени избыточного поля совпадал с хешем имени атакуемого поля. То есть злоумышленник постит форму из трех полей: name, sum и некое-имя-чей-хеш-равен-хешу-первого-поля. В результате интерпретатор извлекает первое поле в переменную $_POST['name'], затем второе поле в $_POST['sum'], а содержимое третьего поля "по ошибке" (по хешу-индексу) заносит в $_POST['name']. Это так называемая коллизия хешей.