Насчет фильтрации и хранении данных.

Тема закрыта
1.09K
.
Брррр почитал, аж голова разболелась!!!
.
nVirus
У mysql_real_escape_string() Есть свои приколы, она не все кавачкы икранирует, и иногда бывает, а у меня очень часто, ошибка записи при обычных кавычкаъ... ''
Лучше фильтровать через check() хоть она и многое режет, но надежнее. Там вырезается всё, что можно.
СУГУБО ИМХО.
.
╭∩╮ (`-`) ╭∩╮
nVirus (17.07.2009/09:05)
У mysql_real_escape_string() Есть свои приколы, она не все кавачкы икранирует, и иногда бывает, а у меня очень часто, ошибка записи при обычных кавычкаъ... ''
Лучше фильтровать через check() хоть он
Чтоб дать правильный ответ, давай заглянем в теорию.

Для чего нам вообще нужно резать кавычки?

Тут опять таки, нужно разбить на 2 пункта.
1) Мы принимаем данные от пользователя и добавляем их в базу данных.
2) Мы извлекаем данные из базы и выводим их в браузер (чаще всего)

Опять вернемся к первому вопросу, для чего резать кавычки?
Ответ - для исключения SQL инъекции.
mysql_real_escape_string() как раз и предназначена для этого. Она экранирует те кавычки (') которые интерпретируются базой как коммандные и являются опасными.
Другие кавычки не представляют для нас опасности при добавлении в базу данных.

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

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

К примеру, избавиться от ошибок XHTML на форуме мне удалось только тогда, когда я полностью исключил функцию check() при добавлении данных, а разбил фильтрацию на вход-выход, как я писал выше.
.
AlkatraZ, Это да, но у тебя в форуме посты то обрезаются и если фильтровать данные через check(), то они все записываются в формате (не помню как звать (), а если такое обрезать, получается ошибка в xhtml... Я если честно фильтрую только через htmlspecialchars() с полным вырезом всего, что можно ), пришлось это делать из за функции mysql_real_escape_string(), которая у меня почти постоянно вызывала ошибку при оденарных кавычках. Юзерам это ужс как не нравилось... Ну а вообщем я с тобой согласен на счёт фильтрование входящих и отображаемых данных, это самое приемлимое ))
.
Да ну нафиг, check() надо при добавлении юзать, ибо при выводе сильно пострадает генерация
.
Studentsov, Генерация генерацией, но все же при выводе лучше всего применять htmlspecialchars() и другие подобные функции. Это можно хорошим тоном считать, но не наоборот.
.
Piks (21.07.2009/13:15)
при выводе лучше всего применять htmlspecialchars() и другие подобные функции. Это можно хорошим тоном считать, но не наоборот.
естественно лутше, большинство кодеров на это и перешли раньше не замечал, все фильтровали (ну или не фильтровали ) а сейчас наконец то пришли к верному решению..ведь данные нужно хранить в той форме в которой они поступают от юзера, а уж вывод их совсем другая история
.
Tzeentch (21.07.2009/13:43)
естественно лутше, большинство кодеров на это и перешли раньше не замечал, все фильтровали (ну или не фильтровали ) а сейчас наконец то пришли к верному решению..ведь данные нужно хранить в той
Я тест проводил, генерация в 2,5 раза сокращалась если мой способ юзать
.
Studentsov, Это капля в море. Порой, есть места, которые на много больше увеличивают генерацию, в этом направлеоии и нужно капать.
.
Studentsov, ну как те сказать, это хорошо, но тут не центер управления полетами, где каждая нано секунда важна и тем болие эт сайт для вап мастеров, а вводимые данные должны быть без ограницений т.к вылаживают коды скриптов, а вот если джон был чатом, где скорость важна, и данные эт тока текст, тогда полностью с тобой согласился бы
Всего: 29