Какой классический формат приема и обработки данных с формы?

Question

[Bjornie]

К примеру скрипт обрабатывает форму, передающую данные разных типов из нескольких полей методом post, которые надо проверить, отфильтровать, и безопасно занести в базу.

Каким является универсальный шаблон для таких процедур? Т.к. как я это вижу:

if (isset($_POST[])) { // Проверяем пришли ли какие-то данные через POST
  if (isset($_POST['name'])) { // делаем какую-нибудь проверку на установленную переменную
    $name = htmlspecialchars($_POST['name']); // при необходимости также trim, real_escape_string
    $surname = htmlspecialchars($_POST['surname']); // при необходимости также trim, real_escape_string
    $query; // пишем запрос, используя подготовленные запросы (pdo или mysqli)
    // выполняем запрос в БД
    // получаем ответ от БД
    // обрабатываем ответ (success/fal) и реагируем
    $db->close(); // закрываем соединение
  }
}

Является ли это корректным вариантом приемом данных? Что я забыл?

1) Что если поступает много строк, нужно ли каждую обрабатывать вручную или для нее есть специальные фильтрующие функции, которые делают всё сразу?
2) Стоит ли делать какие-то дополнительные проверки по-умолчанию всегда?
3) Каким в идеале должен быть блок else (если запрос не POST), die()? Редирект? Что-то другое?

Спасибо.

Answer 1

[xmoonlight]

1. Проверка всех входных и выходных данных - только Regexp по "белому" списку.
Иначе говоря - принимаем только ожидаемые значения.
preg_match();
Используем те же правила проверки (js+regex) на клиентской стороне сайта (в браузере) перед отправкой данных на сервер.

2. Закрываем соединение с базой только тогда, когда оно уже более не нужно для текущего исполнения PHP-скрипта до конца его работы. обычно, соединение к базе закрывается перед началом формирования страницы по шаблону. Можно закрывать ещё точнее: после завершения работы последнего запроса из последнего модуля списка всех модулей, участвующих в работе с данными в базе.

И на последок маленькая, но ОЧЕНЬ! полезная функция собственного производства:

function validfilter($value,$regexp,$flags='usi') {
  if (preg_match('/'.$regexp.'/'.$flags, $value,$result) && $result[0]===$value) 
     return $value;  
  else return false;
}

Answer 2

[Александр Х]

1. ну как вариант - filter_var_array; имена лучше прогонять по белому списку, выше про это уже писали, но это уже от проекта зависит;

2. в приступах паранойи, я иногда заворачиваю все в base64 перед сохранением куда-либо; структурированные данные - json_encode + base64_encode. избыточно ли это? наверное, да ))

3. эмм.. а что бы вы хотели, чтобы происходило? ))

Comments

[Bjornie]

3. заполняю форму, посылаю ее на script.php методом post. Если post == выполнить блок, а если нет? Если обратился напрямую? Или что-то еще? Хочется узнать про такие случаи )

[Александр Х]

3. вопрос в том, какое задумано поведение системы - сообщить об ошибке юзеру? сообщить админу по мылу, что нас ломают? не сохранять, но визуально проигнорить ошибку, чтобы сканер/бот не поняли, что их спалили? профильтровать данные и сохранить хоть както? перенаправить на страницу с правилами заполнения?

вариантов-то можно придумать 100500, а правильный зависит от проекта и конкретной формы.

[Bjornie]

Александр Х: и такой ответ сойдет. спасибо :)

Answer 3

[Arman]

Надо сохранять в БД так как прислал пользователь, если его данные прошли валидаторы! Нельзя что-то менять, пользователь не это прислал, и такая попа будет чтоб вернуть ему то что он до этого прислал. Менять можно, например, пароль хранить в виде хэша или эл.почту в нижний регистре, можно поправить тип данных (POST всегда в виде строки, а вам надо целое число или булеан), если БД noSQL типа. htmlspecialchars актуален для html страниц, а если вам надо будет отправить данные мобильному приложению, что мобильное приложение будет делать с & l t ; и т.д.? Получается вам надо только писать валидаторы, чтоб в БД не было мусора и экранировать кавычки чтоб не было SQL-инъекций. А вот когда показываете, тогда уже надо думать что безопасно показывать, а что надо экранировать чтоб не было XSS-инъекций и т.д.