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

вообщем, мое личное мнение: метод небезопасный и не универсальный

есть же два чудных варианта: PEAR и шлюзы данных (относительно последнего - есть несколько типовых решений) 

Приведи их!



Ты ошибаешься.


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




а аргументировать ты так и не смог.

 

" ' "
" ',' "
" (' "
" ',`"




сразу становится понятно, что метод безопасен, надежен и универсален...

По моим предположением, если через GET или POST злоумышленник такое отправит, то взлом скрипта не произойдет. Запрос просто не выполнится, что и требуется. Согласен? Где опастность?


На практики же приведенные тобой символы передавать нет никакой необходимости НИКОГДА. Поэтому я, как разработчик, ни с какими ограничениями не сталкиваюсь. Зато уверен, что неэкранированным НИЧЕГО не пройдет. Надежность повышается.

    

А я как то вообще не ломаю себе голову по поводу всего этого...
идем в пхп.ини и ставим magic_quotes=on
И все уже в скрипт попадает "слешованое".
 

экранирует не все. что mysql_escape_string 

Если в БД будет ложится то что приходит от клиента через GET/POST/Cookies data то этого хватит.
В дургих случаях, когда например данные поступают из потока(файла) - согласен, надо использовать свой механизм. 

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

Brother's Company

И все, ошибка. Примеров таких полно. И тебя пользователи просто засыпят письмами.

З.Ы. Не уверен насчет русских сайтов, но на английские точно (у них же ' весьма сильно используется в языке)
 

А оно поддерживается без проблем. 

Кстати, кто-нибудь знает, зачем mysql_real_escape_string экранирует \r\n ?

Из комментариев в манеале:


Если их не квотить запрос может получиться вида:

Т.е. \n\r будут относиться не к тексту, а к запросу, т.е. в базу вставиться единая строка, безе переводов строк..

Я тоже не согласен с таким подходом. Если вызывать эту функцию, то она проэкранирует все без исключения входные параметры, но ведь некоторые параметры могут не использоваться в запросе, тогда их придётся обратно деэкранировать, а это лишняя работа.
ИМХО надо просто писать класс абстракции БД и в него вшивать проверки. Это, конечно, тоже не очень красивый вариант (его сложно грамотно реализовать), но более удобного вариант для пользователя (для пользователя класса \программиста\) и не придумаешь.

Я же, в своей практике просто все запросы выношу в функции, которые возваращают уже "готовый продукт", и в этих функциях проверяю все входные параметры (это гораздо проще). Этот подход не очень нагляден, но для средних проектов наиболее подходит \на мой взгляд\

А по поводу того, что:



Взломщики придумывают всегда самые нереальные входные параметры. Это неоспоримо.

Это вы по отношению к какой функции?

К предложенной WOWA

\правка\
Уф... после бурного НГ внимательность на нуле. =) не считается

Это сообщение отредактировал(а) coyl - 4.1.2007, 00:50

да, это недостаток конечно.. 

Сейчас я думаю, что самым мудрым решеним является создание функций для Инсерта и Апдейта отдельных.

И передавать значения в функции через массив.

типа:



А функция update тогда уже заэкранирует все эти символы. Точно также и с Инсертом.
Кроме того, тут очевидный плюс то, что легче переменные указывать.. Меньше вероятность ошибки, когда через INSERT что-то не в тот столбец  запишешь.

Что вы думаете по этому поводу?