Форум PHP

$a=htmlspecialchars(stripslashes($a));
Уберите stripslashes()

Poison, при обработке htmlspecialchars(); перед выхлопом сообщение с тэгами превратится в пособие по HTML для новичков...
Ralph, действительно, я об этом и не подумал! Изменения в обработке не затронут сами сообщения)
Вобщем, все понятно, все работает на ура, спасибо всем, кто принял участие!

Или к примеру у меня тэг[mail]...[/mail] заменяется на ссылку <a href="mailto.php?id= И вдруг мне понадобилось файл mailto.php перенести из главного каталога в каталог ext.Во ВСЕХ сообщениях останется некорректная ссылка и для норм.работы мне придется менять ВСЕ сообщения,вместо того,чтобы изменить ОДНУ строку в файле обработки bb-кода на выходе...То же со смайлами...

А зачем ? Я лично вообще сторонник того,чтобы инфа хранилась как есть,без искажений.А уж при выводе или др.использовании делай с ней что хошь...А то потом вылазят всякие баги типа при выводе обрезанного анонса новости получишь не вышел новый автомобиль "Лада"...,а вышел новый автомобиль "Лада&quo...

А почему бы не преобозовать BB при добавлении в БД?

Вывод из всего вышесказаного:

<?php if(!empty(trim($_POST['a']))) { if(get_magic_quotes_gpc()) $_POST['a']=stripslashes($_POST['a']); $into_query=mysql_escape_string($_POST['a']); //запрос INSERT с записью $into_query } ?>

Вывод информации

<?php  //данные из таблицы считаны в $a $a=htmlspecialchars(stripslashes($a)); //функция MyTags($val) определена ранее, производит обработку []-тэгов $a=MyTags($a); echo $a; ?>

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

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

Что касается bbCode: да, надо преобразовывать теги перед выводом.
Но это не существенно замедлит генерацию страницы, если, конечно, RegEx написаны грамотно.

Многое для меня прояснилось в этом вопросе. Но есть еще непонятки: mysql_real_escape_string это та же mysql_escape_string с расширенной функциональностью или она применяется специфически?
Может, лучше применить именно mysql_real_escape_string ?
И еще- как же все таки с ВВ кодами? Если Вы рекомендуете прописать htmlspecialchars(); именно на выходе, то придется делать обработку ПОСЛЕ ее вызова, а т.к. будут использованы regexp'ы, это существенно замедлит вывод страницы. Как обычно поступают в подобных случаях? Подскажите, опыта маловато....

>

<?php >$query="SELECT * FROM `table` WHERE `nick`='$nick'"; >?>

>$nick="aaa' OR `nick`='admin"; как Вам такое значение?

А никак. Здесь Вы играете незаэкранированным символом ' апостроф, а вовсе не символом ` обратная косая кавычка.

>В одной из вышеприведенных тем была Ваша реплика о безопасности с такой фразой: "...С
>программным исключением возможности подключения файлов из целевой папки в поток кода..."
>1) Как это делается?
например, не применять операторы подключения кода (include / include_once / require / require_once) - вообще. Или хотя бы не применять их с параметрами, в которых фигурируют входные аргументы.

Ограничить загрузку файлов пользователя определенными папками.
Сохранять файлы под собственными именами.
Запретить выдачу апачем файлов из этих папок с произвольными MIME-типами
Запретить интерпретацию php в этих папках.
и т.д.


>2) Что допустимо и что не допустимо в сценарии, чтобы этого избежать?
В общем случае - ничего не допустимо. Всё что допустимо - допустимо в индивидуальном порядке.

<?php $query="SELECT * FROM `table` WHERE `nick`='$nick'"; ?>

$nick="aaa' OR `nick`='admin"; как Вам такое значение?
В одной из вышеприведенных тем была Ваша реплика о безопасности с такой фразой: "...С
программным
исключением
возможности
подключения
файлов из
целевой папки в
поток кода..."
1) Как это делается?
2) Что допустимо и что не допустимо в сценарии, чтобы этого избежать?

P.S. Кажется, начинаю понимать:
главное- экранирован ' , а ` не опасен, т.к. закрыт после имени столбца=)
Ну, с прогрессом меня;)