Форум сайта python.su
nerezusЗависит от задачи. В общем случае фильтровать нетекстовые символы (все, а не только \0) надо на входе, т.е. при получении данных от пользователя, так как они могут многое сломать ещё до подстановки в шаблон. Хотя на выходе тоже не помешает.
def escapeHtml(s):
return s.replace('&', ‘&’).\
replace('"', ‘"’).\
replace('\'', ‘'’).\
replace('<', ‘<’).\
replace('>', ‘>’).\
replace('\0', '')
Достаточно безопасно? За основу взят http://php.net/htmlspecialchars и добавлено \0
Офлайн
cgi.escape()хм, примерно то же, что я и написал, но без \0. отя не знал про эту функцию.
т.е. при получении данных от пользователя, так как они могут многое сломать ещё до подстановки в шаблон.Например? Чем это может навредить?
Офлайн
nerezusВезде, где ожидаются только текст. Например, если внутри используется XML-RPC для передачи данных между компонентами системы. Большинство генераторов XML (например, ElementTree) не проверяют данные на наличие недопустимых символов, хотя должны давать ошибку. Зато большинство парсеров (например, expat, используемый тем же ElementTree) ведёт себя корректно - дают ошибку. Заметьте, генераторы должны давать именно ошибку, то есть данные в любом случае должны быть оччищены, а исправление этого типового бага в генераторах упростит отладку, но не решит саму проблему.т.е. при получении данных от пользователя, так как они могут многое сломать ещё до подстановки в шаблон.Например? Чем это может навредить?
Офлайн
> но не решит саму проблему.
Стоп, а так проблема же в генераторах. Им дают данные, а они только должны их обрабатывать.
А по твоим словам мы изначально должны портить(как ты говоришь, преобразовывать) данные. Хотя проблема не в данных, а в кривых генераторах.
Офлайн
nerezusДа, есть проблема с генераторами. Они считают, что если в XML может быть только текст, то пользователь им будет скармливать только текст. Хотя неплохо бы поменьше доверять пользователю и проверять.
Стоп, а так проблема же в генераторах. Им дают данные, а они только должны их обрабатывать.
А по твоим словам мы изначально должны портить(как ты говоришь, преобразовывать) данные. Хотя проблема не в данных, а в кривых генераторах.Это почему же портить? Если мы принимаем (требуем) от пользователя текст, а он шлёт нам не текст (точнее, текст + несколько недопустимых символов, попавших туда из-за кривого браузера или злого умысла), то у нас есть 3 пути: 1) довериться пользователю (по нему следуют большинство, из-за чего многие сайты так легко сломать), 2) послать его куда подальше (хороший вариант, но виноват может быть не только пользователь, но и кривой браузер) или 3) убрать/заменить недопустимые символы. Мне больше нравится 3-й путь, потому ему и следую.
Офлайн
ods А не легче ли преобразовывать текст тогда только на передаче в XML для передачи в XML? А для вывода только перед выводом?
Офлайн
nerezusНу шаблонный фильтр это как никак функция. А вообще в django.utils.html есть функция escape, на основе которой фильтр и сделан.
Daevaorn мм, не нашел… Вернее я нашел только | escape в шаблонах. Но я просто не хочу пользоваться Django'вскими шаблонами
Офлайн
Daevaorn
хы, там так же сделано:
return html.replace('&', ‘&’).replace('<', ‘<’).replace('>', ‘>’).replace('“', ‘"’).replace(”'", ‘'’)
Офлайн