Есть одна мелочь.
Как лучше писать

и почему?

Будь добр, в следующий раз называй тему адекватнее. Невнятно названные темы будут удаляться
Короткий ответ на вопрос: безразлично, в какой из двух вариантов форме писать.
Развернутый ответ: ни так, ни так писать не надо.
Во-первых, mysql_escape_string - морально устаревшая функция. Вместо неё надо использовать mysql_real_escape_string, которая безопаснее и надежнее.
Во-вторых, функция используется перед вставкой переменной в динамически формируемый запрос к MySQL. Для других целей лучше использовать другие средства.
mysql_real_escape_string экранирует 
Таким образом исключается ситуация, вроде такой:

в случае чего будет попытка выполнения следующего запроса:

Благодаря подсветке синтаксиса, сходу видно, что работать нормально такой запрос не будет.
Вот при формировании запроса эту функцию и используй.
Кроме того, у тебя недочет:

вернет ошибку(точнее - предупреждение/Warning) если скрипту через GET не был передан параметр "е". Потому лучше сделать проверку на isset. Впрочем, ещё лучше - не запихивать в отдельную переменную значение, которое и так у тебя никуда не денется($_GET).


Это сообщение отредактировал(а) skyboy - 16.11.2007, 00:45

В чем глубинный смысл вопроса?
Писать две инструкции в одной строке или на двух?

vasac, видимо - проверять данные при получении или уже перед использованием 

спасибо. Буду теперь использовать mysql_real_escape_string а нет ли на этом форуме темы, где написаны различия между mysql_escape_string() и mysql_real_escape_string()

Если верить мануалу, mysql_escape_string() идентична mysql_real_escape_string(), исключая то, что mysql_real_escape_string() принимает параметром ещё и указатель на соединение и экранирует в зависимости от кодировки. mysql_escape_string() не делает этого и результат работы не зависит от кодировки, в который вы работаете с БД.

PS я бы еще посоветовал перед применением этих функций, проверить, включены ли магические кавычки (get_magic_quotes_gpc()). А то, может быть, экранировать ничего и не надо. (а может быть, лучше будет в данном случае на входе применить stripslashes(), а уже на выводе mysql_real_escape_string() ).

kasmanaft, во первых не понимаю смысл экранировать. Если выводить на экран, или подсвечивать - то это не нужно, я думал mysql_real_escape_string(); - надежнее или новее. Мне это для селектов, или для инсертов, не для выводов.

Для них экранировать и нужно, почему - см. ответ skyboyя или PHP FAQ:  \"Кавычки \". Cоставление запросов mysql, слеши, экранирование кавычек.


Можно сказать и так 


Действительно лучше, т.к. поведение magic_quotes зависит и от других настроек (подробнее в FAQ выше).

SelenIT, стоп. Зачем на выходе что то делать вообще? Если записалось по нормальному. то и выведется по нормальному.

m1kle, смотря что и куда выводить. Если текст сомнительного происхождения (напр. запись в гостевой или форуме) выводится на HTML-странице, то нужно учесть, что злоумышленник мог вписать туда, например, яваскрипт, который ворует авторизационную куку юзера и отсылает на чужой сервер. Это называется XSS-уязвимость. Или просто навставлять левого HTML (напр. кучу закрывающих </td></table>) и поломать дизайн страницы. Чтобы подобный фокус не мог сработать, нужно как-то обработать текст перед выводом - проще всего с помощью htmlspecialchars.

Это сообщение отредактировал(а) SelenIT - 17.11.2007, 00:51

на htmlspecialchars я проверяю

А mysql_real_escape_string() так же как и mysql_escape_string() следует использовать на входе, а не на выходе.

Конечно. Это ж по сути то же самое, только "более новое и надежное";)

А еще точнее - не "на входе", а при подстановке данных в SQL-запрос.

Да, извиняюсь, неправильно выразился.. На выводе, конечно же, нужно применять htmlspecialchars(), а при запросе чего-либо в БД - mysql_real_escape_string().

...предварительно очистив полученные данные функцией stripslashes(). (если включены магические кавычки)

Это сообщение отредактировал(а) kasmanaft - 17.11.2007, 10:29

и так ко всем входящим данным stripslashes применять? не проще ли отказаться от magic quotes, используя set_magic_quotes_runtime?

quotes_runtime и quotes_gpc разные вещи. gpc в момент исполнения уже не отключишь.

Так оно разве спасет? Я, честно говоря, до сих пор не понял чего делает эта функция.

эта функция, по-моему, отключает magic quotes.
vasac, я ошибаюсь?

magic_quotes_gpc нельзя отключить в сценарии, так же, как и register_globals, так как их действие происходит до начала выполнения.
Для конкретной папки/сайта можно отключить в .htaccess если php стоит, как модуль.
quotes_gpc экранирует входящие параметры из _GET, _POST, _COOKIE...
runtime при получении из базы, файлов и т.п. Вот её отключить можно.

Т.е. 100% защишенный скрипт это

Только вот stripslashes() нужно применять при включенных магических кавычках, а в htmlspecialchars() желательно передавать второй параметр "ENT_QUOTES"

Т.е. 

Это сообщение отредактировал(а) kasmanaft - 17.11.2007, 14:57

m1kle, не 100%-ый. См. первую часть ответа kasmanaftа и - обязательно - PHP FAQ.

SelenIT, а у kasmanaftа 100%й?

95%-ный . С точки зрения прослешивания кавычек для такого простого случая - все в порядке. Но на случай отсутствия $_POST['a'] нужно предусмотреть логику более явно - например, инициализировать $a значением по умолчанию. Иначе в строке 4, по идее, все равно будет Notice о несуществующей переменной...

100%-защищенный скрипт это скрипт написанный программистом стопроцентно понимающим что он делает.
Вы не понимаете.
Вы выводите данные, пропущенные через mysql_escape_string на экран.
Разберитесь в каких случаях, какие проблемы возникают и какие есть способы их решения, а не валите всё в кучу.

Так?

Уже лучше