Тип переменной из $_POST

[igortik]

Тип переменной из $_POST

Привет!

Стоит задача определить тип элемента супер-глобального массива $_POST, приходящего после отправки пост-запроса из формы.
gettype говорит, что любой из элементов массива является строкой, кроме тех, кто приходит в виде массива.

P.S. Что мешает определять как именно экранировать или приводить к integer данную переменную.
Заранее тип переменных я не хочу определять, т.к. хочу создать функцию, которая будет производить экранирование или приводить к иному типу переменную налету, получая элемент массива $_POST.


Реально ли?

 

[Фанат]

Реально ли?

gettype говорит, что любой из элементов массива является строкой

Что мешает определять как именно экранировать или приводить

просто экранируй все подряд.

Если подумать, то смысла в таком определении - 0 целых, 0 десятых.

 

[dimagolov]

igortik, тебе не нужно экранировать данные из $_POST "оптом при получении". экранироание нужно делать при использовании таких данных, а при составлении запроса известно какого типа поле и как проверять таки данные на корректность и экранировать их.

http://phpfaq.ru/slashes

 

[igortik]

*****
Таки-да... уже думал об этом. Хотел задать вопрос по части - а как быть с float-типом, если в базу нужно отправить int, а потом все же решил делать проверку на стороне клиента в таком случае... реальному пользователю все равно необходимо подсказывать что он забыл ввести и где ошибся, я тем, кто напрямую будет отправлять постом значения флоат-типа от этого не легче, учитывая структуру таблицы базы...

dimagolov
Целиком согласен, но пора уже как-то оптимизировать время разработки..

 

[HraKK]

Для этого есть такое понятие как фильтры.
Прочитайте хоть в Zende том же как они сделаны.

-~{}~ 15.02.10 21:58:

igortik
проверять надо на 2 сторонах.

 

[Beavis]

igortik
Правильно, оптимизировать надо, но не так.
Ты экранировать для чего собираешься, для записи в базу, или для вывода в HTML ?

 

[igortik]

Я так понимаю, однозначного мнения нет.

1. Если все проверять тем же форм-валидатором на стороне клиента, а на стороне сервера просто эскейпить, то беды не будет.

2. Если все делать по правилам, то надо и на стороне клиента и приводить к нужному типу в скриптах. Также все будет четко и лаконично с точки зрения допустимой функциональности скрипта.

В обоих случаях мы не допустим фиктивного запроса к базе, я так понимаю.

 

[Beavis]

igortik
Мнение есть однозначное: данные, полученные от пользователя, необходимо эскейпить непосредственно в запросе к БД.

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

 

[igortik]

Beavis
да записи в базу.

Логически форма строится на последовательности ее элементов, кнопка является последним, в принципе, что позволяет проектировать алгоритм обработки пост-запроса и удалить последний элемент массива перед экранированием в цикле.....

но вот мнения однозначного я пока с Вашей стороны не получил относительно "корректности" юзать mysql_real_escape_string ко всему, что движется... Но и с *****ом согласен, т.к. это также не повредит.

 

[Beavis]

А все проверки на стороне клиента - это только для удобства клиента. На безопасность это влиять никак не может.

 

[igortik]

Beavis
Да это тоже ясно как Божий день.
Я следую логики - защитить клиента от некорректного выполнения mysql-запроса, если приду к выводу, что mysql_real_escape_string панаценя и не стоит делать акцент на точном приведении типов перед самим запросом, а что касается левых постов, то это уже другое русло

 

[Фанат]

Beavis

данные, полученные от пользователя, необходимо эскейпить

за такие слова надо бить по голове молотком.
поскольку источник получения данных НИКАКОГО отношения к искейпингу не имеет.

 

[Beavis]

igortik
При использовании нормальных библиотек для работы с базой ты просто пишешь что-то типа $db->query("UPDATE tbl SET name = ?", $name)
И вместо плейсхолдера подставляется экранированное значение параметра.
А к нужному типу база данных сама всё приведет, не беспокойся, она это умеет.

 

[Фанат]

igortik
при чем здесь формы вообще какие-то?
валидация-шмалидация никакого отношения к работе с бД не имеет.

 

[Beavis]

Автор оригинала: *****
Beavis

за такие слова надо бить по голове молотком.
поскольку источник получения данных НИКАКОГО отношения к искейпингу не имеет.

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

 

[igortik]

*****
Я говорю с точки зрения задачи, где я буду это использовать.

Все ясно ведь по тексту, что забирать пост я буду после отправки формы, а валидация на стороне клиента элементарным js поможет реальному пользователю, который по ошибке ввел вместо int - float тип или наоборот, избежать ошибки mysql-запроса...

 

[dimagolov]

Beavis, зачем весь этот флейм, если все доходчиво описано в FAQ-е, разве что можно еще к уже данной ссылке дать автору изучить материал http://phpfaq.ru/safety

 

[igortik]

не гоните друг на друга, пожалуйста.

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

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

 

[dimagolov]

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

-~{}~ 15.02.10 16:26:

экономить свое время на операторах приведениях к нужному типу для корректного запроса к базе

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

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

прямо обратно. фильтры на клиенте это по желанию, а валидация на корректность данных бизнес-процессам и корректная подготовка запросов SQL это обязательно на сервере, хотя и прямо друг с другом не связаны.

 

[igortik]

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

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

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

-~{}~ 15.02.10 23:29:

dimagolov
Да, действительно, с профессионализмом подходишь, очевидно.
Я тоже сторонник прямых методов, а не закоулков... но все же хотел спросить...