Автоматическая очистка POST в проекте?

Question

[Uber Noob]

В новом рабочем проекте столкнулся с тем, что массив $_POST автоматически переносится в некую переменную, назовём её $P в которой данные уже очищены, т.е. безопасные. Предприсывается пользоваться именно этим массивом по соображениям безопасности.

Нормальная ли это практа и если нормальная то вопрос только один:
Как при очистке и перемещении $_POST->$P предусмотреть абсолютно всё. Ведь в некоторых формах может приниматься небольшой текст, в некоторых цифры, в некоторых e-mail, в некоторых большой текст где разрешены спецсимволы типа +,=,! и т.д. Или идея в том, что тупо экранируется все специсимволы и без вопросов?

Comments

[Сергей delphinpro]

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

[Uber Noob]

Сергей, спасибо, не ну я просто думаю вдруг я настолько нуб что все уже давно так делают, а я не в курсе

[Алексей]

Uber Noob, Если бы это было нормальной практикой, то это делали бы все повсеместно. Скорее должно удивить, что никто этого не делает и задаться вопросом: почему? Бессмысленно писать универсальную функцию на все случаи жизни. Проще работать с каждым параметром отдельно через валидаторы.

Answer 1

[Алексей Скобкин]

массив $_POST автоматически переносится в некую переменную, назовём её $P

Что практически бессмысленно.

Нормальная ли это практа

Нет. Посмотрите, как работает Symfony HttpFoundation, например. Там никто ничего не очищает. Безопасность обеспечивается в разных слоях приложения по-разному. В работе с БД - с помощью подготовленных запросов, при выводе данных - с помощью замены HTML-сущностей или экранирования и т.п.

Как при очистке и перемещении $_POST->$P предусмотреть абсолютно всё.

Никак.

в некоторых формах может приниматься небольшой текст, в некоторых цифры, в некоторых e-mail, в некоторых большой текст где разрешены спецсимволы типа +,=,! и т.д.

Это вопросы валидации, а не очистки данных, скорее.

Answer 2

[Александр Гамов]

Введи правила оформления названия инпута. К примеру name="date_inputname" И при обработке пост, спаршивай имя инпута от 0 символа до "_". Вот тебе и название метода которым этот инпут проверять.

Comments

[Uber Noob]

Проект не мой, я бы такой шнягой заниматься даже в таком виде не стал

[ThunderCat]

и в базе хранить поле как inputname?

[Александр Гамов]

ThunderCat, в переменной хотели сказать ? вполне идея.
Понятно что это по сути велосипед и выше дали хороший пример на примере Symfony (сам работаю с ларкой).

[ThunderCat]

Александр Гамов, ок. На клиенте пишем подмену а ля text_id вместо int_id, и вот уже у нас ид проверяется как текст. Чет не очень.

[Александр Гамов]

ThunderCat, Верно, не подумал.