Форум PHP

Эта функция, как известно, экранирует кавычки. А как вернуть текст, обработанный этой функцией, в исходный вид? Я додумался только до обработки текста строковыми функциями.

Позвольте поинтересоваться, а для чего это может быть нужным?

Редактирую текст сообщения в гостевой книге, новость в новостном модуле...

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

P.S. Это, кстати, происходит не только из-за этой функции, но и когда включен режим магических кавычек на сервере.

А зачем обрабатывать POST функцией mysql_esqape_string()? Ведь она для этого совсем не предназанчена. Отсюда и проблемы. Ведь даже в названии первое слово указывает на принадлежность mysql
Обрабатывайте данные непосредственно для запроса, а остальные не трогайте. И не нужно будет лишний раз stripslashes()
Если дело не в магических кавычках однако...

>Если дело не в магических кавычках однако...

Именно в них. Заставлять же клиентов лезть в настройки интерпретатора и отключать магические кавычки - сами подумайте...

>>Если дело не в магических кавычках однако...
>
>Именно в них. Заставлять же клиентов лезть в настройки интерпретатора и отключать магические кавычки - сами подумайте...

Вообще-то это и в .htaccess прописывается. Для тех клиентов, что не в состоянии по-человечески настроить php

А если сервер вообще .htaccess не позволяет использовать? Как тогда быть? Мне попался как-то такой сервер.

а) Требовать от хостера отключить эту переменную в конфиге.
б) по условию get_magic_quotes_gpc() напустить stripslashes() на все три суперглобальлных массива через array_map / array_walk. Где-то тут были примеры... Loki писал и я вроде тоже...
Одно другого не исключает :)

>б) по условию get_magic_quotes_gpc() напустить stripslashes() на все три суперглобальлных массива через array_map / array_walk. Где-то тут были примеры... Loki писал и я вроде тоже...

Имеено об этом я и хотел узнать. Перебрать массывы я могу, главное, как удалить эти пресловутые слэши. Я додумался только до str_replace() и preg_replace().

Я в ответе хеопсу 26.09.2009 в 18:21 поисковую ссылку дал - выжимку коллективного разума на рассматриваемую тему. Загляните.

Вот, к примеру решение автора Николай2357

function rec_stripslashes($mixed)  {      if( is_array($mixed) )      {          return array_map('rec_stripslashes', $mixed);      }      else      {          return stripslashes($mixed);      }  }  if( get_magic_quotes_gpc() )  {      $_GET = rec_stripslashes( $_GET );      $_POST = rec_stripslashes( $_POST );  }

упрощая

function rec_stripslashes($mixed)  {      return  is_array($mixed) ? array_map('rec_stripslashes', $mixed) : stripslashes($mixed);  }  if( get_magic_quotes_gpc() )  {      $_GET = rec_stripslashes( $_GET );      $_POST = rec_stripslashes( $_POST );  }

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


Да... и не просто пораньше. А исключительно первым пунктом.
Хороший кандидат на этот ... php_include_prep_code или как он там...

а какая разница между

if( get_magic_quotes_gpc() )  {      $_GET = rec_stripslashes( $_GET );      $_POST = rec_stripslashes( $_POST );  }

и

if(!get_magic_quotes_gpc() )  {      $_GET = mysql_real_escape_string( $_GET );      $_POST = mysql_real_escape_string( $_POST );  }

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

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

>Ваш подход провоцирует более частые ошибки в методах обработки данных.

Вы же меня и научили этому подходу)))

>>Ваш подход провоцирует более частые ошибки в методах обработки данных.
>Вы же меня и научили этому подходу)))

Где именно и супротив какого?
вообще слэши не ставить?

>мне второй больше нравиться,

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

>я уже привык к нему и

Так и я привык. Отвыкать пришлось. Теперь за фотографии стыдно.

>сложностей не возникает.

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

офтоп.
>Мне вот тоже нравится мясо по-французски.
С удивлением недавно узнал, что оливье во Франции называют - "русский салат" ))

ну а если кинуть в корень сайта php_value magic_quotes_gpc off, можно забыть про оба, и больше не ломать себе голову подобными рассуждениями про горе разработчиков языка. Или такое решение тоже по каким-то причинам неверное?

это одно правило.
второе - про экранирование при формировании строк - выполнять всё равно придется.

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

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

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

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

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

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

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

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

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

>сами подумайте...
Я то подумал... Только не вижу никакой связи между магическими кавычками и mysql_escape_string().
Вы бы сначала разобрались что для чего и откуда беруться слэши.

Связь прямая. Базу данных (SQL или файловую) нужно заполнять, заполнять, как правило, из HTML-форм, т.е. получать данные методом POST или GET. Практически ни в одном приложении этого обойти невозможно. Т.е. проблема магических кавычек встает в полный рост - нужно либо экранировать данные, либо нет, в зависимости от того включены они или нет. Если информация пошла на почту или в файл - задача обратная - нужно либо удалять их, либо нет, в зависимости от того включены они или нет.

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

Связь косвенная. Потому что а) данные в запрос могут поставлять совсем другие источники нежели GPC и б) запросы могут формироваться совсем другими инструментами (bind, placeholders и т.п.)
И данные нужно экранировать всегда, независимо от того, испортили их уже или еще нет.
Иначе и вправду уязвимостей не избежать.

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

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

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

Не нужно мне приписывать ход мыслей, который бы вы хотели, чтобы у меня был. Речь шла про POST и GET - разумеется во всех других случаях, когда данные поступают в обход механизма GPC необходимо данные экранировать. Косвенность тут на втором месте стоит - на первом месте стоит убыток и лишняя трата времени на анализ ситуации. Нет таких простых слов, которые бы позволили быстро и ясно разработчикам принимать автоматическое решение по поводу магических кавычек. Связано это ещё и с тем, что вы не всегда имеете дело с суперглобальными массивами, иногда с переменными в которых хранятся значения из них. Если бы можно было использовать прозрачное правило, которое ушло бы на уровень второй сигнальной системы - я бы давно его донес бы до достаточно широкой аудитории, благо каналов предостаточно. Такого правила нет - это всегда анализ и разбор: нельзя сказать экранируйте все при первичной обработке или экранируйте все перед вставкой - выбрали стратегию и придерживайтесь её. Сейчас мало придерживаться стратегии - ещё нужно и анализ проводить чуть ли не всей цепочки следования переменной. Вопрос экранирования - это вопрос дисциплины кода, отсутствие магических кавычек не решат автоматически всех проблем, сложности и ошибок, однако, сделают ситуацию прозрачнее и более масштабируемой.

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

>Такого правила нет - это всегда анализ и разбор: нельзя сказать экранируйте все при первичной обработке или экранируйте все перед вставкой - выбрали стратегию и придерживайтесь её.
А очень жаль, что нет. Особенно когда приходится разбирать чужой код. закрадываются смутные сомнения и очень неуютно, когда данные попадают в запрос как таковые. Совсем неясно, экранированы они на входе или нет.

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

>Не нужно мне приписывать ход мыслей, который бы вы хотели, чтобы у меня был.

Ход мыслей я не приписываю - он для меня загадка совершенно однозначно. А вот набор предлагаемых подходов - безусловно.

>Речь шла про POST и GET - разумеется во всех других случаях, когда данные поступают в обход механизма GPC необходимо данные экранировать.

И что, легче держать в голове, откуда данные пришли, и исполнять кодом эту мантру каждый раз " О! Раз данные не GPC, придется экранировать..."? Или раз и на всегда забыть, о том, что данные могут быть экранированными? И работать с ними просто как с аморфным потоком символов?

>Косвенность тут на втором месте стоит - на первом месте стоит убыток и лишняя трата времени на анализ ситуации.
Так я ж о том и говорю!

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

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

Ну почему же нет-то?
Есть такие слова.
Магические кавычки - ошибка разработчиков php-языка (и интерпретатора), вызванная (не будем о том, чем именно) . Ошибка безусловная. И должна быть устранена. Из-за порождения изрядного количества кода под эту ошибку написанного, устраняется мягко, а не топором.

>Связано это ещё и с тем, что вы не всегда имеете дело с суперглобальными массивами, иногда с переменными в которых хранятся значения из них.

>Если бы можно было использовать прозрачное правило, которое ушло бы на уровень второй сигнальной системы - я бы давно его донес бы до достаточно широкой аудитории, благо каналов предостаточно.


Вот Вам правило. Перед тем, как апострофами обрамить строковое значение, с целью сформировать строку языка MySQL, значение должно быть пропущено через mysql_real_escape_string(). Точка. И будет Вам скразу и дисциплина кода, и его надежность, и его прозрачность. И никак оно не нарушается никакими промежуточными переменными.

В них просто не должен храниться экранированный необлепленный апострофами текст. Как не принадлежащий никакому осмысленному языку. Но это уже не часть правила.



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

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

>Из ваших слов читается, что если бы меня не существовало, то и проблемы бы никакой не было :)
Вынужден с такой точкой зрения не согласиться.
И я не соглдасен - не надо мне эту точку зрения приписывать. Я вовсе не считаю Вас причиной проблемы.
Я прекрасно понимаю, что проблему самих кавычек Вы видите.
Просто, на мой взгляд, Вы - один из людей, которые заблуждаются на предмет того, каким образом с ней можно эффективно справляться. Ну и в силу обстоятельств, имеющий возможность такое заблуждение распространять.
Распространять очень широко. Перед этой самой упомянутой Вами аудиторией.

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

Безусловно.
Я так её и применяю.

UPD.Поправка.
про причине внутренней неряшливости, частенько применяю менее строгий аналог mysql_escape_string() , отчетливо осознавая, впрочем, что беда от него будет только на мультибайтовых, отличных от utf8 данных.

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

См. ответ Commander'у (26.09.2009 в 17:36)

Мы об этом с cheops'oм и спорим.
Я считаю, что нельзя одновременно решать две проблемы. Он - что можно (последнее время удалось сдвинуть его на мнение "существуют два подхода").

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

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

Проблема ещё хуже, нет такой одной функции, которая бы эту проблему решала. При помощи stripslashes() можно отрезать те слеши, которые существуют в тексте, но которые не прошли через методы POST, GET и т.п. или прошли но с отключенными кавычками. Поэтому ситуацию из-за них нужно анализировать каждый раз - четко понимая, что, где и зачем вы отрезали - иначе можно попортить текст.

Ну, в моих скриптах 99% (если не все 100) проходят через $_GET или $_POST, так что мне пока не имеет смысла беспокоиться об этом.

>Честно говоря, не понял сути вашей дискуссии. По моему, проблема существует - режим магических кавычек кучу неприятностей создает. Раз отключить его при помощи функции языка нельзя, нужно устранять это теми методами, которые существуют (stripslashes()).

конечно и безусловно.

Но вот человек хочет написать stripslashes и останавливается в раздумьи... а вдруг sql-запрос делать.. а там mysql_escape_string писать придется... а у меня тут уже всё готово...да ну...
Я протестую против этого.

А ещё проблема заключается в том, что используется два подхода для решения проблемы "магических кавычек":
1) Экранировать, если они не включены
2) Резать, если они включены
По мере решения проблемы конкретного разработчика, темы обрастают философскими рассуждениями и методическими спорами, как вы можете видеть в этой теме. Что ещё больше запутывает и запугивает разработчиков, которые смотрят, читают и думают "да провались все это, буду делать как раньше".

> и думают "да провались все это, буду делать как раньше".

И ведь проваливается. :)
Философии в моем тексте не было ни на полпальца. :)) Кто там одеяло тянет? :)

Я не обвиняю вас в философии, скорее уж себя :))). При неортогональном подходе всегда будет несколько решений и уж доводы за найдутся в любом из этих подходов, сообенно, если в конструкциях языка заложены предпочтения в пользу одного из таких подходов (меньшая количество строк и повышенная читабельность - это основа основ любого стиля программирования). Если строится ортогональный язык - не нужно брать за основу неортогональный Perl. Другое дело, что PHP - это язык-сорняк, он приживается в отрасли вопреки, а не благодаря.

>читают и думают "да провались все это, буду делать как раньше".

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

Её используют по другой причине: mysql_real_escape_string() тербует соединения с базой данных, mysql_escape_string() - нет.

ну я-то про себя писал, у меня эта причина неактуальна.
А другие - да.

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

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

Мне именно это и нужно. Приведу код:

<?php //Здесь извлекаем новость из БД ... $news = mysql_fetch_array($query_result); //Извлекаем текст новости из $_POST $news_text = $_POST['news_text'];//Работает magic_quotes_gpc() if (empty($news_text)) $news_text = $news['text']; $news_text = new field_textarea("news_text","Текст новости",true,stripslashes($news_text)); ... if(!empty($_POST)){ ... if(empty($error)){ $news_text = mysql_escape_string($form->fields['news_text']->value); } } ?>

ясно, что если не убрать cлэши, то в тексте новости, при наличии в ней кавычек или слэшей появятся экранирующие слэши. То есть, magic quotes мешается.

Пока имеются магические кавычки, никуда вы от фукнции get_magic_quotes_gpc() не уйдете, какой бы подход не использовался - кавычки вам могут отключить в любой момент. Поэтому следует скорее работать так

<?php  //Здесь извлекаем новость и БД  ...  $news = mysql_fetch_array($query_result);  //Извлекаем текст новости из $_POST  if(get_magic_quotes_gpc()) {   $news_text = stripslashes($_POST['news_text']);//Работает magic_quotes_gpc()  } if (empty($news_text)) $news_text = $news['text'];  $news_text = new field_textarea("news_text","Текст новости",true,$news_text);  ...  if(!empty($_POST)){  ...  if(empty($error)){  $news_text = mysql_escape_string($form->fields['news_text']->value);  }  }  ?>

PS Правда, если вы используете класс field_textarea(), тогда из метода error() следует исключить et_magic_quotes_gpc().

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

>PS Правда, если вы используете класс field_textarea(), тогда из метода error() следует исключить et_magic_quotes_gpc().

Что за метод error()? Может быть, Вы имеете в виду функцию check()?

>Что за метод error()? Может быть, Вы имеете в виду функцию check()?
Да, конечно :)

C этим советом Вы в десятку попали - я про это просто забыл бы, а потом искал бы с неделю.

P.S. Кстати, а как Вы в своих скриптах эту проблему решаете?

Собственно проблемы такой нет, если всегда помнить откуда у вас переменная и как её следует обрабатывать. Рано или поздно потребуется вызывать обе функции (экранирования и удаления слешей). Трианон утверждает, что лучше пораньше вызвать stripslashes(), чтобы исключить саму вероятность возникновения 1% трудноулавливаемых ошибок, путь и ценой более сложной организации кода. Наверное в этом имеется рациональное зерно, особенно, когда код разрабатывает сильный разработчик. Ещё лучше обстоит дело, если вы пропускаете все POST и GET данные через единый обработчик - в нём можно реализовать любой подход: резать или экранировать. В зависимости от выбранного подхода строить всю окружающую обвязку.

>Ещё лучше обстоит дело, если вы пропускаете все POST и GET данные через единый обработчик - в нём можно реализовать любой подход: резать или экранировать.

Я именно так и делаю.

<?php function GetParam($name,$defvalue){ $result = $_GET[$name]; if (empty($result)){ $result = $_POST[$name]; } if (empty($result)) $result = $defvalue; if (get_magic_quotes_gpc()){ $result = stripslashes($result); } } ?>

При извлечении информации из $_GET или $_POST экранирующие слэши удаляются. Если необходимо получить данные из $_POST, либо, если $_POST пуст извлечь данные из бд пишем так:

<?php $news_text = GetParam("news_text",$news['text']); ?>

Текст, лежащий в бд, уже обработан функцией mysql_escape_string(), так что функция stripslashes(), вызываемая в функции GetParam(), также удалит ненужные слэши. Так что, проблема решается применением этой функции однозначно.

>Текст, лежащий в бд, уже обработан функцией mysql_escape_string(), так что функция stripslashes(), вызываемая в функции GetParam(), также удалит ненужные слэши.

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

>Так Вы выкините живые, годные слэши.

Какие слэши Выс имеете в виду? Если там окажется слэш, который написан в тексте администратором, то он будет экранирован. А все остальные мне как раз и надо убрать. Перед добавлением же этого текста снова в бд я его снова пропущу через mysql_escape_string().

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

А Вы смотрели, что именно лежит в базе? Если положено туда по правилам.

И так ясно, что в базе лежит. Ведь все, что туда попадает, обрабатывется при помощи mysql_escape_string(), следовательно, кавычки и слэши в любом случае будут экранированы. А если эти данные через $_POST пойдут, то экранирующие слэши сами будут экранированы.

Я почему и задался вопросом. Все, что находится в бд или проходить через $_POST необходимо прогнать через stripslashes(), чтобы убрать лишние слэши, а перед помещением в бд - снова обработать mysql_escape_string(). Иначе администратор, редактируя новость, сообщение в гостевухе и т.д. при наличии в тексте кавычек натолкнется на экранирующие слэши. А после этого в тексте, который пройдет через $_POST, экранирующие слэши сами будут экранированы. Отсюда и получается, что, если несколько раз отредактировать текст, то все кавычки сопровождаются целым сонмом слэшей.

С чего Вы решили, что БД хранит записанные в нее данные вместе с экранирующими слэшами?
А если в БД данные заносились по другим схемам, которые слэшей вообще не применяют?
А если необходимо сравнить одно с другим?
Чего проще в конце концов исполнить пару операторов:

INSERT INTO `tbl` (`id`, `name`) VALUES (1, 'O\'Henry'); SELECT * FROM `tbl`;

Да и просто SELECT 'O\'Henry'; поглядеть - уже о многом скажет.

Так нет, Вы же уперлись в свое видение - и ни с места.

>Так нет, Вы же уперлись в свое видение - и ни с места.

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

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

>Наверное в этом имеется рациональное зерно, особенно, когда код разрабатывает сильный разработчик.

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

>Собственно проблемы такой нет, если всегда помнить откуда у вас переменная и как её следует обрабатывать.

Так вот и проблема на мой взгляд, что нужно это помнить. И даже не особо это важно. Сама логика разработки скрипта подсказывает...
Допустим мне (как и автору) нужно занести данные из POST в базу и вернуть в форму. Первым делом инициализация:

<? $data = !empty($_POST['data'])?$_POST['data']:NULL;

Всё, уже на этом этапе проблема - никому не нужные бэкслэши. Их никто не просил появляться, они сами. Значит тут и надо это исправить. То есть очистить POST от последствий. В настройках, .htaccess или stripslashes, но сразу. Решил проблему и забыл. Не нужно больше

>всегда помнить откуда у вас переменная

Так же и с запросами. Если данные попадают в запрос, то их обязательно нужно к этому подготовить. Литеральные или числовые, не важно, важно чтоб туда ничего не попало в чистом виде. И опять не нужно ничего помнить. Просто обработай и всё.
А главное, что не нужно вспоминать через пару месяцев - как я их готовил и готовил ли...
И тем более если это не я...
По этому я и не вижу никакой связи между магическими кавычками и mysql_real_escape_string() к примеру.

>Перетягивание одеяла на мой взгяд с одного конца проблемы на другой, не решающий в данном случае проблемы в целом (увеличенный риск возникновения ошибки).

Ошибкой Вы называете попадание грязи (т.е. слэшей) в данные?
Так этот риск исключается еще более простым набором штатных шагов. На подкорке.
php.ini: get_magic_quotes_gpc 0
корень .htaccess: php_value get_magic_quotes_gpc 0
и конечно же stripslashes+array_map на старте скрипта применительно к тройке суперглобальных массивов при условии get_magic_quotes_gpc().

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

неужели продавил?

С этой задачей справится функция stripslashes ().

Спасибо огромное, cheops. А я все думал, как бы с этой проблемой справиться?

Кстати, а если этой функции встретится комбинация из двух обратных слэшей? Она оба удалит? Если оба, то добавить в текст обратный слэш будет невозможно.

P.S. OFF. Не понял, почему такое название темы. Я вроде назвал ее : "mysql_escape_string()" без единой русской буквы.

Нет, только один, так как два идущих подряд слеша - это символ экранированного слеша.

То есть эта функция - "отменятель :)" mysql_escape_string()?

Скорее "отменятель" фнукции addslashes(). Хотя из-за магических кавычек её используют очень часто, так как есть две стратегии - либо все магические кавычки сначала убрать и потом обрабатывать данные в предположении, что их сроду не бывало, либо экранировать данные, только тогда, когда режим магических кавыыек выключен.

.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()

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

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

Нет слов.

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

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

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

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