Django-rest-framework: Échappement (esperluette) dans les URL d'API navigables.

Créé le 20 juin 2014  ·  26Commentaires  ·  Source: encode/django-rest-framework

Lorsque des URL avec un caractère échappé (en particulier dans mon cas, et une esperluette) sont rendues dans l'API navigable, dans le href, elles sont incorrectement non échappées. Cela ne peut s'appliquer qu'aux esperluettes.

Par exemple, cette URL:
http: // localhost : 8000 / endpoint /? param1 = Oui +% 26 + Non & param2 = quelque chose

Serait rendu comme:
http: // localhost : 8000 / endpoint /? param1 = Oui + & + Non & param2 = quelque chose

L'URL est correctement rendue dans la valeur de l'élément a ... cela ne s'applique qu'au href.

Bug

Commentaire le plus utile

Je veux juste confirmer que cela fonctionne maintenant :)

J'adore cette bibliothèque, elle fonctionne déjà très bien, mais elle s'améliore encore! 👍

Tous les 26 commentaires

Toutes mes excuses pour la lenteur de la réponse.
Est-ce juste le rendu qui est différent ou le code HTML source lui-même est-il sans échappement?

Salut Tom, dans le HTML, cela ressemblait à ceci:

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

Merci, ça vaudrait peut-être la peine d'essayer d'écrire un cas de test qui échoue pour cela.
Idéalement, cela ne ferait qu'exercer BrowsableAPIRendererer , mais serait probablement également acceptable avec un test d'intégration complet.

Bien sûr, j'en serais ravi. En parcourant la suite de tests maintenant ... l'emplacement approprié serait-il dans RendererEndToEndTests dans test_renderers.py?

Ça me va.

Cela a à voir avec le smart_urlquote Django qui est appelé par urlize_quoted_links de

smart_urlquote appelle unquote avant quote , ce qui supprime l'original. Cela a été ajouté dans https://github.com/django/django/commit/b70c371fc1f18ea0c43b503122df3f311afc7105 et rétroporté pour Django 1.5+.

Alors, nous soucions-nous que ce ne soit pas strictement ce que le client verra, ou devons-nous simplement fermer cela?
Sémantiquement, c'est toujours correct.

Pousser cela du bogue au nettoyage, car c'est limite.

Guide DjangoCon - examen général de ce ticket - quel comportement attendriez-vous, est-il acceptable tel quel?

Je suis aux sprints django-con et je peux travailler dessus. Je n'ai pas contribué auparavant, donc j'ai peut-être besoin de quelques conseils initiaux. Je lis actuellement les directives des contributeurs pour DRF et après avoir exécuté les tests localement, je pourrais aller bugger quelqu'un en personne ou sur irc.

Gotcha - n'hésitez pas à me cingler sur IRC, ou Twitter si je ne suis pas réactif là-bas.

Clôture en raison d'une faible priorité et d'un manque de progrès.
Heureux de reconsidérer si quelqu'un est motivé pour reprendre cela.

@tomchristie Je comprends que c'est un problème mineur, mais c'est toujours un bogue. Si vous cliquez sur le lien, il va à la mauvaise URL. Il semble plus approprié de marquer comme faible priorité que de fermer un problème valide.

Je l'examinerai quand j'aurai le temps.

Désolé d'avoir compris cela différemment - que l'URL n'était pas erronée, juste qu'elle rendait le lien dans un style sans échappée, ai-je mal compris?

C'est à dire. raison de la balise cleanup avez-vous compris que c'était un problème cosmétique?

Oh je vois. Oui c'est correct. Fondamentalement, la valeur href et la valeur d'affichage sont échappées, au lieu de la valeur d'affichage uniquement.

Merci pour une si grande bibliothèque, btw!

Désolé, encore une fois :)

Oui c'est correct.

Corriger que c'est un problème cosmétique, ou corriger que j'ai mal compris et que c'est un bogue? :)

Corrigez que c'est un bug. :)

Clôture, car cela est corrigé par https://code.djangoproject.com/ticket/22267

Vous n'avez pas encore regardé cela, mais devons-nous extraire autre chose étant donné que nous dupliquons «urlize»? Dans quelle version ce problème est-il également résolu? Aussi, super! Yay!

Cela ne semble pas être corrigé dans 1.7.1, donc 1.7.2 ou 1.8? C'est le comportement que je vois avec 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+&amp;+No'

.. et actuel responsable de la branche master de django:

>>> 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 origine une copie modifiée de django.utils.html.urlize ? https://github.com/django/django/blob/master/django/utils/html.py#L255 -L352 est significativement différent, mais je ne peux pas dire la raison de la version séparée. Il semble qu'il doit être recopié.

Oui, il a été copié, car l'original ne fonctionnerait pas pour les liens de style " http://example.org " qui ont des guillemets simples ou doubles les entourant, et il n'y a pas de remplacement facile pour l'autoriser. S'il y a beaucoup de différence, c'est probablement dû au changement progressif de la version de django alors que la nôtre est restée la même.

Nous allons rouvrir cela pour nous assurer que nous avons un ticket d'espace réservé pour nous assurer que cela est résolu.

Abandonner le jalon à ce sujet car il y a des éléments 3.0.1 de priorité plus élevée.

Je me demande s'il est possible d'extraire le cas de test défaillant de # 2014

Ce commentaire https://github.com/tomchristie/django-rest-framework/pull/2014#issuecomment -61525348 implique que ce problème a été résolu dans Django en amont. Fermer ceci, mais rouvrira si quelqu'un confirme que cela reste un problème.

Je veux juste confirmer que cela fonctionne maintenant :)

J'adore cette bibliothèque, elle fonctionne déjà très bien, mais elle s'améliore encore! 👍

Cette page vous a été utile?
0 / 5 - 0 notes