htmlspecialchars - дело верстальщика или программиста?

[Фанат]

htmlspecialchars - дело верстальщика или программиста?

Недавно я поспорил с Демиургом в одном топике, кто должен делать ЭТО.

Сейчас, в другом тоопике про XSS, я вспомнил о той дискуссии.
И, пожалуй, еще больше укрепился в своем мнении.
Вот на чем строится моя позиция:
1. XSS. Все, что не является хтмл кодом - должно быть прохтмлспециплчарено. просто по определению. Во избежание.
2. собственно, мы разделяем шаблон и и наполняющие его данные. ПОСКОЛЬКУ программер шаблона не касается - значит но должен выдавать данные без тегов! Кроме тех случаев, когда у него в бд хранится уже оформленный текст.
посмотрите на XML? Он вообще работать не будет без htmlspecialchars. Именно в силу таокго разделения.

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

 

[Crazy]

Лично я предпочитаю вариант, при котором в шаблон передаются просто данные и уже верстальщик выбирает, нужно ли квотить, и если нужно, то по каким правилам: html, uri, javascript.

 

[svetasmirnova]

Полностью согласна с Crazy
Фанат! Попробуй вставь в JS код htmlspecialchars текст. Помнится, недавно в топике про mod_rewrite (там человек хотел все апострофы в переменных GET экранировать для защиты от SQL-инъекций) ты сам утверждал, что таким образом д'Артаньяна в базе не окажется. Тот же случай, по большому счёту.

 

[Макс]

посмотрите на XML? Он вообще работать не будет без htmlspecialchars.

через CDATA - будет.

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

Вопрос только по html...chars или вообще по использованию пхп-функций (отвечающих только за оформление) в шаблоне ?

 

[Фанат]

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

 

[fixxxer]

а если ли вариант, когда НЕ НУЖНО квотить?

соответственно - пускай верстальщик явно указывает только js/uri-квотинг, а?

 

[ONK]

Пожалуй я изложу свой подход.

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

Однако в 99% случаев выбор метода обработки передаваемых в шаблон данных связан с конкретной спецификой их применения. То есть метод обработки выбирается однократно и может быть изменён только при коренном пересмотре функционального назначения частей шаблона или всего шаблона, а как следстие и корректировки самого скрипта реализующего бизнес логику приложения.

Приведу простой пример:
Есть имя пользователя.
В имени пользоватля потенциально допустимы любые символы.
Для максимальной гибкости последующей обработки такие данные разумнее всего хранить в первоначальном виде, но применение в процессе спользования эти данных могут быть обработаны минимум 4 разными способами:
1. Обработка для помещения в базу данных.
2. Обработка для отображения на html страницах.
3. Обработка для передачи в качестве параметра GET запроса.
4. Обработка для передачи в качестве параметра в клиентскую процедуру (Js, Vb,,,).

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

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

Одним словом я предпочитаю передавать в шаблон данные в предварительно подготовленном виде.

 

[SiMM]

ONK, вопрос на засыпку - если одни и те же данные могут быть использованы как для JS, так и для HTML, одновременно - в вашем случае получается, что надо всё предусмотреть и выдавать верстальщику весь возможный диапазон уже преобразованных параметров? Типа $var_HTML, $var_JS ...? Так ему всё равно придётся думать, где что применять - и в чём же тогда получится плюс?

 

[Фанат]

плюс - в простоте.
в однозначности.
Верстальщик выводит данные. где надо - там и выводит.
И при чем здесь - одни и те же? Какая разница?

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

СОВЕРШЕННО ВЕРНО
именно в этом и состоит работа программиста.
подготовить данные инициализировать переменные.
Чтобы шаблон был все-таки больше шаблоном, а не программой.

 

[ONK]

SiMM, у меня есть блоки в которых я использую одновременно ~html_name~ ~url_name~ и ~js_name~. Тебе кажется что можно спутать их назначение? Это даже короче, чем указание обработчика.

 

[SiMM]

Фанат, это не избавляет верстальщика от необходимости понимать, куда пихать $var_HTML, а куда пихать $var_JS или $var_URI - так какая разница между этими переменными и записью HTML($var), JS($var) и URI($var)?
ONK, дело не в том, что мне кажется, а в том, что я хочу разобраться, что всё же лучше и чем.

 

[Фанат]

SiMM разница - в подходе.
в случае с переменной, верстальщик делает ТО ЖЕ САМОЕ, ЧТО И С ДРУГИМИ переменными.
Со всеми остальными он как-то справляется? Куда их вставить? Без помощи гусар?
А почему ИМЕННО с этими у него вдруг должны возникнуть проблемы?
А потому, что ТЫ КАК РАЗ заставляешь его думать, КУДА пойдет переменная. А ему думать не надо. У него есть переменная и он знает, куда ее вставить. По смыслу. по логике шаблона. Это не одна переменная! Это три разных переменных. В числе прочих. Ничем от прочих не отличающихся.
А ты хочешь, чтобы он какие-то действия совершал.
Вот у тебя и полуится перемешка вместо стройного шаблона.

Скажи мне, мрожно чем-то заменить foreach в шаблоне? Можно ли без него обойтись?
А без твоих функций - можно?
Так, может быть, оставить в шаблоне только действительно необходимое?

 

[ONK]

SiMM, когда тебе даны 3 разных переменных, ты даже обладая знаниями уровня 3 класса (не примай на свой счёт), после однократного разъяснения смысла префиксов сможеш понять что с ними можно сделать.

 

[SiMM]

Автор оригинала: Фанат
А почему ИМЕННО с этими у него вдруг должны возникнуть проблемы?

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

А потому, что ТЫ КАК РАЗ заставляешь его думать, КУДА пойдет переменная.

Так это и так и сяк получается - просто формат разный $var_type vs TYPE($var)

Скажи мне, мрожно чем-то заменить foreach в шаблоне? Можно ли без него обойтись?
А без твоих функций - можно?

Вопросы риторические Думаю, надо просто подождать, пока люди попрактикуются и выскажут своё мнение о том и о другом подходе - пока выводы делать рано.

 

[Фанат]

ты пляшешь от типа.
Ты вносишь новую сущность - тип переменной.
Я же безуспешно пытаюсь тебе обхяснить, что есть набор переменных и есть набор мест, куда их надо вставить.
И все.
Что в них ,какого они типа - неважно.
никакой $var_type для верстальщика НЕТУ
есть $var_name
определенное имя, определенное место.

Вопросы риторические

с чего ты взял, что риторические?
С чего ты взял, что я спрашивал - КАК УДОБНЕЕ?
я спрашивал - без чего можно обойтись, а без чего - нельщя.

 

[SiMM]

Фанат, риторические потому, что ответ, что без foreach обходиться не вижу смысла так же очевиден, как и то, что можно (с точки зрения верстальщика) обходиться без функций. А речь же была о случаях типа ника (он может понадобиться как в html'е, так и в JS, да и в URI, в общем-то, тоже), и префикс - лишь удобство, имхо.

 

[svetasmirnova]

>А потому, что ТЫ КАК РАЗ заставляешь его думать, КУДА пойдет переменная. А ему думать не надо. У него есть переменная >и он знает, куда ее вставить. По смыслу. по логике шаблона. Это не одна переменная! Это три разных переменных. В >числе прочих. Ничем от прочих не отличающихся.
Ну посмотрите.
Делаем обычную HTML-версию, потом хочется RSS и WML, к примеру. Переменная одна и та же: $header
И дальше интереснее: то, что катит в HTML, не катит в XML. То есть теоретически возможно, что программист подсунет верстальщику какую-то вещь, которой быть не должно. В случае с необработанными переменными он скажет: напиши такой-то обработчик, а в случае с размноженными сущностями нарвётся на ошибку. Или ещё пример: данные, которые заносятся в базу, но перед этим проверяются. Помнить, как они должны отображаться внутри полей в случае ошибки: нет уж, увольте!
>после однократного разъяснения смысла префиксов сможеш понять что с ними можно сделать.
Чем проще писать

prefix_varname

instead of

function(var_name}

? В чём разница? Чем мозги верстальщика так сильно нагружает?

 

[Фанат]

Делаем обычную HTML-версию, потом хочется RSS и WML, к примеру

Это хороший довод.

 

[ONK]

По порводу генерирования одного документа в разных форматах я с ходу ничего сказать не могу, таких задач мне решать не приходилось.
Могу лиш задать пару вопросов по RSS и WML:
1 Чем отличаются правила формирования гиперссылок (точнее обработка значений передаваемых параметров), от тех-же в HTML?
2 Чем отличается обработка передаваемых значений содержащих произвольные данные, от тех-же в HTML?

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

 

[Demiurg]

А вы видели верстальщиков, которые полностью сами пишут шаблоны? Мне, почему то всегда вместо шаблона доставался кусок htmlя из которого я делал шаблон и и сам вставлял все названия переменных. И фильтры я тоже всегда указывал сам.

И еще, можно я отойду немного от темы в сторону смарти ?
Так вот понятно, что в большенстве случаев надо данные ескейпить htmlspecialchars. Один из учасников форума для смарти придумал простую вещь. По-умолчанию все переменные прогоняются по htmlspecialchars. Когда же при выводе указаны другие фильтры, или указан спецальный фильтр noescape, данные остаются в чистом виде.

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