Django-rest-framework: Escapezeichen (kaufmännisches Und) in durchsuchbaren API-URLs.

Erstellt am 20. Juni 2014  ·  26Kommentare  ·  Quelle: encode/django-rest-framework

Wenn URLs mit einem Escapezeichen (speziell in meinem Fall und kaufmännisches Und) in der durchsuchbaren API gerendert werden, wird sie in der href nicht ordnungsgemäß entfernt. Dies gilt möglicherweise nur für kaufmännisches Und.

Zum Beispiel diese URL:
http: // localhost : 8000 / endpoint /? param1 = Ja +% 26 + Nein & param2 = etwas

Würde gerendert werden als:
http: // localhost : 8000 / endpoint /? param1 = Ja + & + Nein & param2 = etwas

Die URL wird im Wert des a-Elements korrekt gerendert ... dies gilt nur für die href.

Bug

Hilfreichster Kommentar

Ich möchte nur bestätigen, dass es jetzt funktioniert :)

Ich liebe diese Bibliothek, sie funktioniert bereits großartig, wird aber auch dann noch besser! 👍

Alle 26 Kommentare

Entschuldigung für die langsame Antwort.
Ist es nur das Rendering, das anders ist, oder ist das Quell-HTML selbst nicht entkommen?

Hallo Tom, im HTML sah es ungefähr so ​​aus:

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

Gotcha, danke - es könnte sich lohnen, einen fehlerhaften Testfall dafür zu schreiben.
Im Idealfall würde dies nur BrowsableAPIRendererer ausüben, wäre aber wahrscheinlich auch mit einem vollständigen Integrationstest in Ordnung.

Klar, ich würde mich freuen. Schauen Sie sich jetzt die Testsuite an ... wäre der geeignete Ort in RendererEndToEndTests in test_renderers.py?

Klingt okay.

Dies hat mit Djangos smart_urlquote zu tun, das von DRFs urlize_quoted_links aufgerufen wird und das die Konvertierung innerhalb der durchsuchbaren API übernimmt. Ich denke, der Unterschied zwischen dem Linktext und dem Link selbst mag eine Django-Flucht sein, aber ich bin mir ehrlich gesagt nicht sicher.

smart_urlquote ruft unquote vor quote , was das Original entfernt. Dies wurde in https://github.com/django/django/commit/b70c371fc1f18ea0c43b503122df3f311afc7105 hinzugefügt und für Django 1.5+ zurückportiert.

Interessiert es uns also, dass dies nicht genau das ist, was der Kunde sehen wird, oder schließen wir dies einfach ab?
Semantisch ist es immer noch richtig.

Verschieben Sie dies vom Fehler zur Bereinigung, da es grenzwertig ist.

DjangoCon-Anleitung - allgemeine Überprüfung dieses Tickets - Wie würden Sie das Verhalten erwarten, ist es so wie es ist akzeptabel?

Ich bin bei den Django-Con-Sprints und kann daran arbeiten. Ich habe vorher noch keinen Beitrag geleistet, daher benötige ich möglicherweise eine erste Anleitung. Ich lese gerade die Richtlinien für Mitwirkende für DRF und nachdem ich die Tests lokal ausgeführt habe, kann ich jemanden persönlich oder auf IRC nerven.

Gotcha - zögern Sie nicht, mich im IRC oder auf Twitter anzupingen, wenn ich dort nicht reagiere.

Schließung wegen niedriger Priorität und mangelndem Fortschritt.
Gerne überdenken wir, ob jemand motiviert ist, dies wieder aufzunehmen.

@ Tomchristie Ich verstehe, dass es ein kleines Problem ist, aber es ist immer noch ein Fehler. Wenn Sie auf den Link klicken, wird die falsche URL angezeigt. Es erscheint angemessener, eine niedrige Priorität zu kennzeichnen, als ein gültiges Problem zu schließen.

Ich werde es untersuchen, wenn ich Zeit habe.

Tut mir leid, dass ich das anders verstanden habe - dass die URL nicht falsch war, nur dass sie den Link in einem ungeklärten Stil wiedergab. Habe ich das falsch verstanden?

Dh. Grund für das cleanup -Tag, verstanden, dass dies ein kosmetisches Problem ist?

Oh, ich verstehe. Ja das ist richtig. Grundsätzlich werden sowohl der href- als auch der Anzeigewert maskiert und nicht nur der Anzeigewert.

Danke übrigens für diese tolle Bibliothek!

Entschuldigung, noch einmal :)

Ja das ist richtig.

Richtig, dass es sich um ein kosmetisches Problem handelt, oder richtig, dass ich es falsch verstanden habe und es ein Fehler ist? :) :)

Korrigieren Sie, dass es ein Fehler ist. :) :)

Schließen, da dies durch https://code.djangoproject.com/ticket/22267 behoben wird

Haben Sie sich das noch nicht angesehen, aber müssen wir noch etwas anderes herausholen, da wir 'urlize' duplizieren? Auch in welcher Version ist das gelöst? Auch toll! Yay!

Dies scheint in 1.7.1 nicht behoben zu sein, also 1.7.2 oder 1.8? Dies ist das Verhalten, das ich mit Django 1.7.1 sehe:

>>> 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'

.. und aktueller Leiter der Django-Hauptniederlassung:

>>> 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'

War urlize_quoted_links ursprünglich eine modifizierte Kopie von django.utils.html.urlize ? https://github.com/django/django/blob/master/django/utils/html.py#L255 -L352 unterscheidet sich erheblich, aber ich kann keinen Grund für die separate Version angeben. Es sieht so aus, als müsste es erneut kopiert werden.

Ja, es wurde kopiert, da das Original für Links im " http://example.org " -Stil mit einfachen oder doppelten Anführungszeichen nicht funktioniert und es keine einfache Überschreibung gibt, die dies zulässt. Wenn es einen großen Unterschied gibt, liegt das wahrscheinlich an der allmählichen Änderung der Django-Version, während unsere gleich geblieben ist.

Wir werden dies erneut öffnen, um sicherzustellen, dass wir ein Platzhalterticket haben, um sicherzustellen, dass dies behoben wird.

Löschen Sie den Meilenstein, da es 3.0.1-Elemente mit höherer Priorität gibt.

Ich frage mich, ob es möglich ist, den fehlgeschlagenen Testfall aus # 2014 zu ziehen

Dieser Kommentar https://github.com/tomchristie/django-rest-framework/pull/2014#issuecomment -61525348 impliziert, dass dieses Problem im vorgelagerten Django behoben wurde. Das Schließen, wird aber wieder geöffnet, wenn jemand bestätigt, dass es ein Problem bleibt.

Ich möchte nur bestätigen, dass es jetzt funktioniert :)

Ich liebe diese Bibliothek, sie funktioniert bereits großartig, wird aber auch dann noch besser! 👍

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen