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

если есть, то не нужно.
А если речь идет не о целочисленном значении, а строковом, вы как поступаете?

Добавлено через 30 секунд
bars80080, согласитесь, это совершенно не принципиальный вопрос.

ну  как-то имея глобальную переменную типа $_POST лучше её оставлять в первозданном виде.. А создавая локальную переменную в функции или классе.. так она после обработке исчезнит

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

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

Добавлено через 35 секунд
просто после обработки у меня по определению в запросе не будет "неожиданностей" 

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

Но другим его советовать я бы воздержался. 

Это сообщение отредактировал(а) Ипатьев - 17.9.2009, 21:32

есть такое


и такое есть


ну, это самый оптимальный, ИМХО, метод


у меня в обработке есть формат all, в нём с данными ничего не делается. данные только переприсваиваются массиву заявленных входящих переменных, а если таковой нет, то устанавливается значение по умолчанию. так что, неожиданности возможны
с другой стороны, когда я составляю запрос к БД, то делаю это примерно так:

где класс БД сам всё обработает, и тут уж точно у меня и голова не болит, и все обработки будут применены именно там, где им следует быть

странное суждение... мне кажется что наоборот в больших проектах "экранирование", фильтрацию", "приведение в соответствие" вообще нужно именно выделять в отдельный класс и расширять функционал... В настоящее время я даже сделал класс который просто обрабатывает все "приходящие переменные", т.е. получает к примеру $_POST, а возвращает массив ключ->значение

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

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

   Ох и консерватор
Предлагаю написать разрабам PHP убрать в нём ООП - такой себе огромный костыль, который в принципе никому не нужен так как есть стандартные механизмы работы с данными.
Впринципе это уже холивар на тему стоит ли применять абстракцию и ни к чему не приведёт.

bars80080



Что и требовалось доказать   

А это не зависит от размеров проекта. Просто нужно разделять три операции:
1. Валидация данных. Валидация - проверка дынных на смысловое содержания. Уже из определения оно не может быть централизовано, т.к. система в целом не должна даже представлять какого вида данные ожидает отдельная ее часть. При этом данные никоим образом не должны измениться -- если какие-то данные не подходят по смысловой нагрузке, то они должны быть отправлены на повторный ввод пользователю.
2. Подготовка данных к сохранению. Включает только преобразование данных в безопасный для сохранения вид. При этом данные никоим образом не должны измениться.
3. Подготовка данных к отображению. Опять же, данные ни коим образом не должны измениться. В большинстве случаев, пользователь должен лицезреть именно то, что он ввел в систему. Если это было нечто вроде 

то в таком виде он и должен их просмотреть. Наглядный пример в этом же сообщении строкой выше )
Исключение составляют только задачи, в которых нужно интерпретировать некоторые теги. Например, пользователю разрешено использовать html теги a, strong, em. И вот только теперь, в этом частном случае,  можно говорить о фильтрации. Тут нам нужно отобразить интерпретировать нектороые теги как теги, а некоторые, как текст, т.е. применить фильтр


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

Я вот одного не пойму, почему бы не отказаться от экранирования и не работать с prepared statement?

Добавлено через 6 минут и 4 секунды


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

1. От необходимости экранирования избавляют не prepared statement, а использование placeholders
2. Когда вы вызываете, например, PDO::prepare() это не имеет никакого отношения к prepared statement
3. А какая разница? Таким образом вы просто перекладываете эту работу на одну из стандартных библиотек, но экранирование все равно происходит ). Тут же речь не о том, как именно это делать, а о том что это делать нужно в принципе и где своевремменно это делать

Это сообщение отредактировал(а) solenko - 18.9.2009, 08:08

Лично я - только "за". В смысле посоветовать другим. Лично мне способ не нравится за "ненаглядность".
Но в этом удивительном топике речь идет совсем о другом. 

solenko, я думаю, вы говорите об одном и том же, просто разными словами.
Плюс, насколько я понимаю, в нативных библиотеках никакого экранирования в полном смысле того слова не происходит. Данные просто отправляются отдельными пакетами, раздельно с запросом. Но это не принципиально. Это один из способов безопасной работы с SQL.

Этих способов, включая изобретения из этого топика я насчитал уже 4:

1. строки прослешиваются и заключаются в кавычки, числа приводятся к нужному типу.
2. prepared statements, они же подготовленные выражения, они же placeholders, они же употребленное мной выше слово "подстановки": запрос отдельно - данные отдельно.
3. редко используемая hex-string
4. способ Gold Dragon: физическое удаление спецсимволов из строки.

Самым безопасным следует признать способ номер 2. Хотя не без оговорок. Ибо ничто не помешает программисту собирать запрос с плейсхолдерами точно так же динамически. 
Самым неудачным - то, что придумал Gold Dragon. База данных задумана так, чтобы хранить все символы. Любые. А сознательно ограничивая функциональность БД, мы заранее раскладываем себе грабли, на которые впоследствии обязательно наступим. 

Это сообщение отредактировал(а) Ипатьев - 18.9.2009, 09:35

С PDO как раз не работал. Но Ипатьев прав, я говорил о pg_prepare()
ibase_prepare()

Ипатьев, ну ты прям меня на пьедестал определил  философ...

А может вернёмся к "Авторизации"... Я вообще-то и не утверждаю что база не должна хранить всё что хочется... Вот только ЗАЧЕМ?  Я утверждаю что ВСЕ данные должны приводится в соответствие с задачей... Лично моё мнение, что в имени пользователя (логине) не должно быть кавычек и других спецсимволов, поэтому мне не нужно это экранировать, и я их просто убираю, ну или предлагаю пользователю самому их убрать. Пароль - думаю букв и цифр больше чем достаточно для составления пароля. Да и я не трогаю первоначальные данные вообще и оставляю их такими какими они пришли, для этого и существуют локальные переменные.

Ну уэ если на то пошло, то куда приятнее читать код когда используются функции класса (главное красиво и понятно назвать)


Да и что вы прицепились к слову ФИЛЬТРАЦИЯ?  я уже давно поправился и сказал что имел в виду и даже пару раз уже озвучил конкретно 


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



Это сообщение отредактировал(а) Gold Dragon - 18.9.2009, 12:36

Gold Dragon, вот в этом посте solenko очень подробно все расписал.
У него обработке данных посвящено три пункта. А ваше 

- это только первый из них.
И с ним никто не спорит.
Просто есть еще два.