Jinja: urlencode vermeidet keine Schrägstriche

Nur ein Hinweis @mitsuhiko
Ich habe keine Ahnung warum, aber do_urlencode entgeht immer noch keinen Schrägstrichen, während unicode_urlencode wie erwartet funktioniert.

Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import jinja2
>>> jinja2.utils.unicode_urlencode("http://url.by", for_qs=True)
'http%3A%2F%2Furl.by'
>>> jinja2.filters.do_urlencode("http://url.by")
'http%3A//url.by'
>>> jinja2.__version__
'2.9.dev'

Weil der Filter urlencode Schrägstriche nicht maskiert. Gibt es einen bestimmten Grund, warum es sein muss? Um dies zu verdeutlichen: Es codiert nur Schrägstriche in der Wertposition von übergebenen Schlüssel/Wert-Paaren.

Ich glaube, dies ist das Standardverhalten für Funktionen, die zum Codieren von URLs bestimmt sind. Tools wie http://meyerweb.com/eric/tools/dencoder/ verhalten sich so. Außerdem habe ich mindestens ein Tool in unserem Unternehmen, das erwartet, dass URLs in GET-Anfragen mit Escape-Schrägstrichen übergeben werden.
Außerdem verstehe ich nicht, warum unicode_urlencode innerhalb von do_urlencode mit for_qs=True aufgerufen hat .
Kann sein, dass ich etwas falsch verstehe.

Schrägstriche sind reservierte Zeichen in der Pfadkomponente und das häufigere Verhalten besteht darin, alles außer Schrägstriche dort zu codieren, wenn Dinge gezwungen werden, URL-codiertes Verhalten zu erzwingen. Die Alternative (Schrägstriche in %2f zu codieren) macht nicht einmal Sinn, da die meisten Server diese Anfragen aufgrund von Sicherheitsproblemen komplett ablehnen, da Backend-Server normalerweise %2f und / nicht unterscheiden können die Pfadkomponente, wie sie mit dekodierten Oktetten arbeiten.

Der einzige Teil, bei dem ein Schrägstrich tatsächlich eine sinnvolle Codierung macht, sind Abfragezeichenfolgen und hier funktioniert der dict-basierte Codierer, den urlencode hat, so. Aber auch dort muss kein Schrägstrich codiert werden, sodass es keinen Grund gibt, ihn zu codieren.

Die Funktion urlencode sollte für die meisten Leute standardmäßig verwendet werden, deshalb kodiert sie keinen Schrägstrich. Wenn Sie benutzerdefinierte Anforderungen haben, können Sie die Funktion in Ihrer Filterregistrierung überschreiben.

Okay. Danke Armin.

Hallo, ich habe das gleiche Problem mit dem Ablehnungs-Schrägstrich, hier ist der Code:

jinja2.Template("{{ disks|reject('sameas', '/')|list }}").render(disks=["/", "/mnt/disk0", "/mnt/disk1"])
u"['/', '/mnt/disk0', '/mnt/disk1']"

Ich möchte die Root-Festplatte ablehnen, aber es funktioniert nicht mehr, wie kann ich es lösen?

>>> import jinja2
>>> jinja2.Template("{{ disks|reject('sameas', '/')|list }}").render(disks=["/", "/mnt/disk0", "/mnt/disk1"])
u"['/mnt/disk0', '/mnt/disk1']"
>>> jinja2.__version__
Out[3]: '2.8'

Funktioniert bei mir.

Funktioniert immer noch nicht für mich, @ThiefMaster , wäre das ein Python-Problem? Welche Python-Version hast du verwendet?

    Python 2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import jinja2
    >>> jinja2.Template("{{ disks|reject('sameas', '/')|list }}").render(disks=["/", "/mnt/disk0", "/mnt/disk1"])
    u"['/', '/mnt/disk0', '/mnt/disk1']"
    >>> jinja2.__version__
    '2.8'

Oh.. sameas verwendet is (und Sie können nicht erwarten, dass 'foo' is 'foo' funktioniert). Sie möchten equalto , das == .

Ja, es funktioniert, ich gehöre nicht zur Familie von Jinja2. Danke, @ThiefMaster

Der einzige Teil, bei dem ein Schrägstrich tatsächlich eine sinnvolle Codierung macht, sind Abfragezeichenfolgen, und hier funktioniert der dict-basierte Encoder von urlencode so. Aber auch dort muss kein Schrägstrich codiert werden, sodass es keinen Grund gibt, ihn zu codieren.

Nein, Sie müssen beispielsweise auch / in Benutzernamen und Passwörtern kodieren.
Dies ist der Grund, warum JS encodeURIComponent hat .

Das ist fair genug, aber in der Praxis ist es auch dort nicht erforderlich und die enthaltenen Anmeldeinformationen sind sowieso veraltet. Da es unwahrscheinlich ist, dass diese innerhalb von Vorlagen erstellt werden, ist dies ein Randfall, der nicht wirklich in Betracht gezogen werden sollte.

Ansible verwendet Jinja, und es ist ziemlich üblich, beim Einrichten von Systemen mit Sicherheitsanmeldeinformationen umzugehen. Ich bin gerade auf einen Fall gestoßen, in dem ein automatisch generiertes Passwort einen Schrägstrich enthielt, der nicht durch urlencode , um eine Datenbank-URL zu generieren, was ziemlich bedauerlich ist. Es wäre zwar problematisch, das aktuelle Verhalten zu unterbrechen, aber warum nicht einen zweiten Filter einführen, der den Schrägstrichen entgeht?

Ansible könnte das tun. Eine solche Änderung muss nicht in Jinja selbst vorgenommen werden - es ist erweiterbar genug, um benutzerdefinierte Filter hinzuzufügen oder sogar eingebaute zu ersetzen.

@ThiefMaster Sind andere Anwendungsfälle als das

@danielkza was hindert Saltstack daran, einen Filter bereitzustellen, der dies tut?

@mitsuhiko Warum enthält Jinja dann eingebaute Filter? Ich kann nur vermuten, dass es daran liegt, dass sie in mehreren Anwendungsfällen nützlich sind. Ich habe Ansible und Salt als zwei Beispiele dafür verwendet, wo es wünschenswert ist, Schrägstriche in URLs zu maskieren, und daher wäre es wertvoll, es für alle verfügbar zu haben.

Was ist mit dem Hinzufügen eines safe -Arguments zu urlencode , wie es urllib.url_quote Python hat, so dass standardmäßig Schrägstriche beibehalten werden, aber auf eine Weise, die leicht überschrieben werden kann?

Jinja versucht, einige häufig verwendete Funktionen bereitzustellen. Wir haben zwei Modi für die Urlencodierung, mit denen Sie etwa 95% erreichen. Sie können ganze Abfragezeichenfolgen kodieren, indem Sie ein Diktat kodieren, und Sie können in einen gemeinsamen Satz kodieren, der für Pfade durch urlencode auf Zeichenfolgen gültig ist.

Wir machen nichts anderes als utf-8 oder so. Denn wo würde es aufhören. Es gibt zu viele Teile einer URL, es gibt Iris und alle haben ihre eigenen Knicke. Wenn wir dort sind, warum nicht einfach auch einen Punycode-Encoder für den Netloc bereitstellen?

Ich bin auf dieses Problem gestoßen, als ich versucht habe, eine Datei in einem Gitlab-Repository über API-Aufrufe zu erstellen. Die Gitlab-API erfordert, dass die Schrägstriche codiert werden. Damit das funktioniert, mache ich: {{ myvar | URL-Code | regex_replace('/','%2F') }}. Ich arbeite in meinen Playbook-Aufgaben mit Ansible- und Jinja2-Filtern. Dies könnte eine Problemumgehung für diejenigen von Ihnen sein, die dies treffen, da ich bestätigt habe, dass es funktioniert.

Ich sehe einige Diskussionen darüber, welche Zeichen prozentual kodiert werden sollten, meines Wissens wird dies derzeit in RFC3986 behandelt. https://tools.ietf.org/html/rfc3986#section -2.2

Für meinen Anwendungsfall hat @ahuffman jedoch eine vernünftige

Ich möchte das schließen, weil es wieder aufgetaucht ist. Meine Argumente dagegen waren bereits hier oben, aber ich möchte sie wiederholen, da derzeit tatsächlich ein PR geöffnet ist (#864), der vorschlägt, einen weiteren Filter hinzuzufügen, um die API von GitLab zu unterstützen.

Die API von GitLab ist kaputt, wenn sie hinter allen Arten von Proxy-Setups platziert wird und es offene Probleme gibt ( Beispielproblem ). Ich würde stattdessen vorschlagen, einen Workaround zu dokumentieren und zu dokumentieren, warum die Leute dies nicht tun sollten.

Ein Beispiel für eine Problemumgehung könnte dies sein:

{{ value|urlencode|replace("/", "%2f") }}

Dies ist ein bisschen eine Haltung, aber dies kann die Menschen ermutigen, die Fehler anderer nicht zu wiederholen, die vor ihnen aufgetreten sind.