В шаблонах Django появилось автоэкранирование

hidded

Чорт. Малколм, конечно, даже не подозревал, что с помощью
django.template можно формировать не только html ;).

hidded

Или поломал. Малколм, конечно, даже не подозревал, что с помощью
django.template можно формировать не только html ;).

Daevaorn

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

Boo

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

я тоже об этом подумал. пришлось исправлять свои фильтры

Pashka R.

Или поломал. Малколм, конечно, даже не подозревал, что с помощью
django.template можно формировать не только html ;).

Ну, имхо, большую часть всё же.... но (!) я за то, чтоб это было опционально и по-умолчанию было выключено...

хотя... а много шаблонов не HTML? всё-таки решение есть:

{% autoescape off %}

Иван Сагалаев

Малколм, конечно, даже не подозревал

После этого надо говорить: "это я по себе сужу" :-). Почитай ссылку и ссылки из нее на документацию. Там много и подробно, и в том числе и про не HTML.

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

Ни в коем случае!

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

Но вот про флаг в settings.py возражение как раз простое и железное. Это уничтожает идею о переносимости приложений, потому что приложение не сможет расчитывать на то или другое поведение. В качестве аналогии нужно вспоминать PHPшные "magic quotes", которые включались опцией на сайте. Проблем с этим было очень много.

Иван Сагалаев

я за то, чтоб это было опционально и по-умолчанию было выключено…

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

Помнить же про делание escape вручную на каждый чих — это крайне неэффективное использование мозгов разработчика.

sin

Помнить же про делание escape вручную на каждый чих — это крайне неэффективное использование мозгов разработчика.

Как-то не думал об этом, пожалуй поправлю функцию tpl в моем PHP-движке :) Спасибо за пост!

Mike Ozornin

я за то, чтоб это было опционально и по-умолчанию было выключено…

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

Alex Lebedev

Наконец-то! Очень полезное изменение.

Теперь будет еще одна причина делать следующий проект на Django, а не на Rails. Еще бы миграции довели до ума и интегрировали какой-нибудь аналог Rake...

Deepwalker

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

Хочется, и не буду себя сдерживать, привести пример противоположного поведения - asterisk. Очень много фич, но вот качество кода, это тихий ужас. Субъективное мнение, не претендующее на полноту.

Densetsu no Ero-sennin

и интегрировали какой-нибудь аналог Rake…

А для чего он нужен, если не секрет?

nmike

В качестве аналогии нужно вспоминать PHPшные “magic quotes”...

Смысл автоэкранирования — защитить разработчика от случайного написания XSS-уязвимостей.

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

\' \"

тогда я не совсем понимаю, при чем тут XSS и PHPшные “magic quotes”...? пример из википедии

~> python
Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi

>>> print "<script>alert('xss');</script>"
<script>alert('xss');</script>

>>> print cgi.escape("<script>alert('xss');</script>")
&lt;script&gt;alert('xss');&lt;/script&gt;

magic quotes в php - были выключены по умолчанию не зря...

Mkdir

Ха-ха-ха =) Буквально вчера расставил |escape по всем темплейтам!

Виктор

почуял что-то неладное, когда в админке полезли

<ul class="errorlist"><li>Обязательное поле.</li></ul>

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

Иван Сагалаев

тогда я не совсем понимаю, при чем тут XSS и PHPшные "magic quotes"

Я имел в виду, что "magic quotes" — это пример настройки, от которой зависит написание кода, и которая может быть включена или выключена на разных инсталляциях. Я не имел в виду ничего конкретного по поводу того, что они делают.

nmike

Я имел в виду, что “magic quotes” — это пример настройки, от которой зависит написание кода, и которая может быть включена или выключена на разных инсталляциях. Я не имел в виду ничего конкретного по поводу того, что они делают.

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

Помнить же про делание escape вручную на каждый чих — это крайне неэффективное использование мозгов разработчика.

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

и потом, - а как система может отличить что это именно XSS а не код от разработчика - ведь он по сути тоже является XSS'ом?

Иван Сагалаев

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

"Всегда помнить" и "делать вручную" — не одно и то же.

Приведу аналогию. Компьютеры становятся мощнее, программы становятся более развитыми и автоматизируют труд не только пользователей, но и разработчиков. Раньше у программистов не было ничего кроме ассемблера, потом появились высокоуровневые языки типа Си, которые сейчас уже не кажутся такими уж высокоуровневыми. Сейчас у нас есть языки типа Питона со сборкой мусора, с прямой поддержкой паттернов вроде Итератора или Прокси. Означает ли такой автоматизм в языке, что разработчики разбаловались и избавлены от необходимости думать? Я думаю, что нет. Все развитие компьютерной техники движется по пути автоматизации наработанных подходов, чтобы у людей оставалось время думать над тем, чего компьютеры еще не умеют автоматически. (Хотя разговоры, что, мол, вот в наше время было программирование, а нынешним детям все дается слишком легко, будут, конечно, всегда.)

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

Pashka R.

Иван Сагалаев, переподумал... теперь с вами согласен на все сто :)

Kandalincev Alexandre

не согласен. каждый сайт должен сам под себя подстраивать окружение, явно указывать что ему нужно а что нет.
С тем жe magic_quotes_gpc. Если оно нужно сайту то сделай при вызове скриптов ini_set и явно укажи. если не нужно то явно укажи что не нужно.

Главное тут не что по умолчанию а явность и гибкость настроек.

qewerty

Вот именно, что от сайта, а не от инсталяции сервера. Если нужно отключить, то это можно сделать ЯВНО в главном шаблоне или где-либо ещё. И отдельные приложения, которые вруг нужно будет установить могут сами выбирать что им нужно. Переносимость лучше.

вообще яб назвал такое поведение разработчиков крайне не правильное - это все переписывать придется..

Зато лучше сбросить груз наследия сейчас, пока нету Django 1.0 =), а больших исправлений это не требует:

{% autoescape off %}
...
{% endautoescape %}

Что уже тут упоминалось.

В шаблонах Django появилось автоэкранирование

Комментарии: 21

Добавить комментарий