Форум PHP

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

Вот это самое ужасное.
Внешне - весьма напоминает. Бочка меда прям.
А внутри ложка буколического продукту.

>Вы когда к яндексу для поиска обращаетесь, тоже id внутреннего ресурса вводите?

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

>Или может быть здесь - на форуме по primary key авторизуетесь? Ваш номер - 10804.

Покажите мне на этом форуме хоть одну ссылку, где фигурирует мое имя.

>И таких мелких, но весьма существенных тестов на вшивость профпригодность в тексте условия примерно с полдюжины.

Ну и поставьте задачу на подобные тесты, будем знать где собаки зарыты и как обрабатывать подобные ситуации.

чем-то напоминает это :)

Нет слов.

[поправлено модератором]

>return htmlentities(stripslashes(trim($v)), ENT_QUOTES);
Это не корректно (см. выше).

[поправлено модератором]

.htaccess:

# отключение магических кавычек  php_flag magic_quotes_gpc Off

если нет доступа к .htaccess:

<? if (get_magic_quotes_gpc()== 1) {   function s_slash($v)   {     if (is_array($v))     return array_map('s_slash', htmlentities(trim($v), ENT_QUOTES));     return htmlentities(stripslashes(trim($v)), ENT_QUOTES);   }         if (!empty($_GET))     $_GET     = s_slash($_GET);         if (!empty($_POST))    $_POST     = s_slash($_POST);         if (!empty($_COOKIE))  $_COOKIE  = s_slash($_COOKIE);         if (!empty($_REQUEST)) $_REQUEST = s_slash($_REQUEST); или:         $_GET =!empty($_GET)    ? s_slash($_GET) : NULL;         $_POST   =!empty($_POST)    ? s_slash($_POST)     : NULL;         $_COOKIE =!empty($_COOKIE)? s_slash($_COOKIE) : NULL;         $_REQUEST=!empty($_REQUEST)? s_slash($_REQUEST)     : NULL; }

но при внесении не числовых данных в БД :
mysql_real_escape_string()

Вы когда к яндексу для поиска обращаетесь, тоже id внутреннего ресурса вводите?
Или может быть здесь - на форуме по primary key авторизуетесь? Ваш номер - 10804.

Подзадача поиска по имени как раз и имела целью проверить, что решающий её умеет не только SQL-запросы соствалять, но и параметры ссылок формировать, причем с произвольным содержанием, а не просто с числовым ключом.
И таких мелких, но весьма существенных тестов на вшивость профпригодность в тексте условия примерно с полдюжины.

В задаче 21 ставить ссылку на имя (а не на id имени) считаю нецелесообразным. Если у каждого пользователя есть primary key, то этого условия должно быть достаточно для поиска.

Так вот и получается:
текст нужно обрабатывать всегда. И не для защиты от уязвимостей, а просто для того, чтобы текст во всех примененных представлениях оставался текстом, а не разваливался на куски.
Правда, в таком случае появится стойкость скрипта к некоторым весьма распространенным атакам - но это эффект побочный, а не прямой.(с)
Все-таки посмотрите решение http://softtime.ru/forum/read.php?id_forum=7&id_theme=38424 21 задачи параллельно с этой темой и все встанет на свои места.