Django-rest-framework: Экранирование (амперсанд) в доступных для просмотра URL-адресах API.

Приносим извинения за медленный ответ.
Отличается только рендеринг или сам исходный HTML неэкранирован?

Привет, Том, в HTML это выглядело примерно так:

<a href="http://localhost:8000/endpoint/?param1=Yes+&+No&param2=something">http://localhost:8000/endpoint/?param1=Yes+%26+No&param2=something</a>

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

Конечно, я был бы счастлив. Просматривая сейчас набор тестов ... будет ли подходящее место в RendererEndToEndTests в test_renderers.py?

Звучит нормально.

Это связано с smart_urlquote Django, который вызывается urlize_quoted_links DRF , который обрабатывает преобразование в доступном для просмотра API. Я _ думаю_, что разница между текстом ссылки и самой ссылкой может быть связана с экранированием Django, но я, честно говоря, не уверен в этом.

smart_urlquote вызывает unquote перед quote , что удаляет исходный. Это было добавлено в https://github.com/django/django/commit/b70c371fc1f18ea0c43b503122df3f311afc7105 и перенесено для Django 1.5+.

Итак, заботимся ли мы о том, чтобы это не было _строго_ тем, что увидит клиент, или мы просто закрываем это?
Семантически это все еще верно.

Перемещение этого от ошибки к очистке, поскольку это пограничное состояние.

Руководство DjangoCon - общий обзор этого билета - каково будет поведение, приемлемо ли оно как есть?

Я участвую в спринтах django-con и могу над этим поработать. Раньше я не участвовал, поэтому мне могут понадобиться некоторые начальные рекомендации. В настоящее время я читаю руководство для разработчиков DRF, и после того, как я запускаю тесты локально, я могу найти кого-нибудь лично или через irc.

Попался - не стесняйтесь пинговать меня в IRC или твиттере, если я там не отвечаю.

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

@tomchristie Я понимаю, что это незначительная проблема, но это все еще ошибка. Если вы нажмете на ссылку, она приведет к неправильному URL-адресу. Кажется более подходящим пометить как низкий приоритет, чем закрывать действительную проблему.

Я займусь этим, когда у меня будет время.

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

Т.е. причина для тега cleanup , поняли, что это косметическая проблема?

О, я вижу. Да, это правильно. По сути, экранируются и href, и отображаемое значение, а не только отображаемое значение.

Кстати, спасибо за такую ​​замечательную библиотеку!

Извините, еще раз :)

Да, это правильно.

Исправить, что это косметическая проблема, или исправить, что я неправильно понял, и это ошибка? :)

Правильно, что это ошибка. :)

Закрытие, так как это исправлено https://code.djangoproject.com/ticket/22267

Я еще не смотрел на это, но нужно ли нам что-то еще, учитывая, что мы дублируем urlize? Также в какой версии это разрешено? Кроме того, отлично! Ура!

Кажется, это не исправлено в 1.7.1, поэтому 1.7.2 или 1.8? Вот что я вижу с django 1.7.1:

>>> from django.utils.html import smart_urlquote, escape
>>> escape(smart_urlquote('http://qwerty.com'))
u'http://qwerty.com'
>>> escape(smart_urlquote('http://qwerty.com?blah=Yes+%26+No'))
u'http://qwerty.com?blah=Yes+&+No'

.. и текущий руководитель ветки django master:

>>> from django.utils.html import smart_urlquote, escape
>>> escape(smart_urlquote('http://qwerty.com?blah=Yes+%26+No'))
u'http://qwerty.com?blah=Yes+%26+No'

Был ли urlize_quoted_links изначально модифицированной копией django.utils.html.urlize ? https://github.com/django/django/blob/master/django/utils/html.py#L255 -L352 значительно отличается, но я не могу сказать причину отдельной версии. Похоже, его нужно скопировать заново.

Да, он был скопирован, потому что оригинал не работал со ссылками в стиле " http://example.org ", которые заключены в одинарные или двойные кавычки, и нет простого разрешения, чтобы разрешить это. Если есть большая разница, это, вероятно, связано с постепенным изменением версии django, а наша осталась прежней.

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

Отказ от вехи на этом, поскольку есть пункты 3.0.1 более высокого приоритета.

Интересно, можно ли вытащить неудачный тестовый пример из # 2014

Этот комментарий https://github.com/tomchristie/django-rest-framework/pull/2014#issuecomment -61525348 подразумевает, что эта проблема была исправлена ​​в вышестоящей версии Django. Закрытие, но откроется снова, если кто-нибудь подтвердит, что проблема остается.

Я просто хочу подтвердить, что теперь он работает :)

Мне нравится эта библиотека, она уже отлично работает, но даже после этого становится лучше! 👍