Формы и htmlspecialchars

[Nafania]

Изучаю yii, дошел до вноса данных в базу и заметил, что политика Yii сводится к использованию htmlspecialchars не при вносе данных в базу, а при выводе их оттуда.
На мой взгляд это неправильно да еще и ухудшает производительность.

У кого-либо есть готовые решения, для того чтобы ко всем полям всех форм при вносе в базу (да и не только) автоматически применялся htmlspecialchars.

Вообще, интересно узнать, кто как хранит данные (с htmlspecialchars или использует htmlspecialchars при выводе только) и почему.

[samdark]

Храню два варианта — один экранированный, другой — исходный. При выводе использую экранированный, при редактировании — исходный.

[Nafania]

Ээээ, можно конечно, но это слишком.
Почему при редактировании нельзя использовать undo_htmlspecialchars?

[samdark]

Потому как не всегда дело ограничивается только htmlspecialchars. Бывает markdown, htmlpurifier и т.д.

[Loki]

Можно использовать beforeSave в модели)
Но по моему htmlspecialchars не всегда допустимо использовать перед записью в БД ибо например JS редакторы выдают текст с html. Кроме того в БД html код никакой опасности не представляет, для фильтрации опасных символов есть mysql_real_escape_string. Если нужно отфильтровать что то, лучше использовать фильтрацию по тегам, вырезая опасные(или все кроме допустимых).

[Nafania]

Потому как не всегда дело ограничивается только htmlspecialchars. Бывает markdown, htmlpurifier и т.д.

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

Можно использовать beforeSave в модели)

Ну это для каждой модели писать надо. А если их чуть более чем до фига?

Но по моему htmlspecialchars не всегда допустимо использовать перед записью в БД ибо например JS редакторы выдают текст с html.

Это да, но тут уж пусть решает тот, кто пишет приложение.

Кроме того в БД html код никакой опасности не представляет, для фильтрации опасных символов есть mysql_real_escape_string.

Это другое совсем.

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

Здесь не только в безопасности дело, но и просто в выводе. Ведь когда информация выводится, она в любом случае должна быть обработана htmlspecialchars.
Вывод осуществляется намного чаще, чем ввод.
Отсюда собственно и возникла тема - зачем обработку делать по 10 раз, если можно сделать лишь один и дальше не суетиться.

[Loki]

Можно использовать beforeSave в модели)

Ну это для каждой модели писать надо. А если их чуть более чем до фига?

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

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

Здесь не только в безопасности дело, но и просто в выводе. Ведь когда информация выводится, она в любом случае должна быть обработана htmlspecialchars.
Вывод осуществляется намного чаще, чем ввод.
Отсюда собственно и возникла тема - зачем обработку делать по 10 раз, если можно сделать лишь один и дальше не суетиться.

Ну тут уже сказали. При выводе не в любом случае нужно прогонять через htmlspecialchars ибо можно при вводе отфильтровать данные по своему и при выводе получать уже готовые к показу данные. Как я понимаю на это и рассчитывали создатели фреймворка. Если бы проверка была принудительной то WISWIG редакторы было бы использовать невозможно без костылей.

[Nafania]

При выводе не в любом случае нужно прогонять через htmlspecialchars ибо можно при вводе отфильтровать данные по своему и при выводе получать уже готовые к показу данные.

Любой мало-мальски нормальный текст содержит кавычки, которые вам вывести as is нельзя.

Если бы проверка была принудительной то WISWIG редакторы было бы использовать невозможно без костылей.

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

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

Так делать и буду, но все же хотелось бы видеть возможность из коробки.

[Loki]

Любой мало-мальски нормальный текст содержит кавычки, которые вам вывести as is нельзя.

Только фильтрует их не htmlspecialchars.

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

Вы меня не поняли. Если мы текст из редактора прогоним через htmlspecialchars то мы и при выводе получим выовд кода html ибо символы будут преобразованы. Конечно это вопрос к построителям системы, но большей части программистов было удобнее так.

Так делать и буду, но все же хотелось бы видеть возможность из коробки.

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

[Nafania]

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

Фреймворк как раз навязывает модель использования htmlspecialchars, только при выводе, а не при вводе - о чем я изначально и поднял тему.
Фреймворк борется с последствиями, а не с источником.

Большинство функций вывода данных в фреймворке используют htmlspecialhars.

Представьте, что на странице выводится список чего-либо, предположим список состоит из 100 элементов.
Каждую строку при выводе надо обработать на предмет тех же кавычек. 100 вызовов. На один хит. А если хитов тысяча?
В случае же того, как говорю я, обработка была бы единожды выполнена, и пусть там хоть 100k хитов - обрабатывать уже не надо.
Вот о чем речь.

[samdark]

Да нет, вроде не навязывает. Я при вводе использую, кто-то при выводе.

[Nafania]

Ну я не настолько глубоко знаком с yii как вы, но вот например, базовые вещи - breadcrumbs - использует по умолчанию.
CGridView - использует по умолчанию, CHtml::link - обязует использовать, если не теги ну итд.
Это навскидку, то с чем я столкнулся в последнее время.

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

[Loki]

Фреймворк как раз навязывает модель использования htmlspecialchars, только при выводе, а не при вводе - о чем я изначально и поднял тему.
Фреймворк борется с последствиями, а не с источником.

Не замечал навязывания. Вообще при выводе лишь в некоторых местах CHtml используется htmlspecialchars. Фреймворк позволяет тебе самому выбирать где делать фильтрацию.

Большинство функций вывода данных в фреймворке используют htmlspecialhars.

Функции для работы с БД не используют htmlspecialchrs. Откуда информация?.. Сейчас пробежался поиском - функция используется только в фильтрах и в классе CHtml где большинство функций?..

Представьте, что на странице выводится список чего-либо, предположим список состоит из 100 элементов.
Каждую строку при выводе надо обработать на предмет тех же кавычек. 100 вызовов. На один хит. А если хитов тысяча?
В случае же того, как говорю я, обработка была бы единожды выполнена, и пусть там хоть 100k хитов - обрабатывать уже не надо.
Вот о чем речь.

Сейчас нет принудительной фильтрации при выводе. Нет. Только в виджетах, и то опционально.
Представьте другую ситуацию - на странице есть текстовый редактор который сохраняет в базу текст с html который не нужно фильтровать. А при фильтрации из коробки, о которой администратор не знал прикручивая редактор, он отфильтруется и на выходе мы получим набор символов а не наш форматированный текст. Поэтому я и говорю что то что есть сейчас в Yii - оптимальный вариант. Пользователь сам может выбрать когда и как фильтровать. Я не против вашего метода, я клоню к тому что из коробки он не нужен.

Возможно моя стратегия в данном плане неправильна

Нет, почему, тут дело в другом) Просто вы упомянули что нужно сделать возможность принудительной фильтрации изкаробки, а это будет уже навязываение) В остальном же как кому удобнее)

[Nafania]

Да, в основном в виджетах, но там везде по умолчанию включен htmlspecialchars, что говорит о стратегии разработчиков.

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

[samdark]

CHtml::link ничего не энкодит вроде… В остальных немногих местах есть возможность отключить.