Jinja: لا يفلت urlencode من الشرطات المائلة

مجرد تنبيهmitsuhiko
ليس لدي أي فكرة عن السبب ، ولكن لا يزال do_urlencode لا يفلت من الشرطات المائلة ، بينما unicode_urlencode يعمل كما هو متوقع.

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'

لأن الفلتر urlencode لا يفلت من الشرطات المائلة. هل هناك سبب محدد لضرورة ذلك؟ لتوضيح ذلك: يقوم فقط بترميز الشرطات المائلة في موضع قيمة أزواج المفتاح / القيمة التي تم تمريرها.

أعتقد أن هذا سلوك قياسي للوظيفة المخصصة لتشفير عناوين url. أدوات مثل http://meyerweb.com/eric/tools/dencoder/ تتصرف بهذه الطريقة. لدي أيضًا أداة واحدة على الأقل داخل شركتنا تتوقع أن يتم تمرير عناوين URL داخل طلبات GET بشرطة مائلة مائلة.
أيضًا ، لا أفهم سبب استدعاء unicode_urlencode داخل do_urlencode مع for_qs=True .
قد أفهم شيئًا خاطئًا.

الشرط المائلة عبارة عن أحرف محجوزة في مكون المسار ، والسلوك الأكثر شيوعًا هو ترميز كل شيء باستثناء وجود خطوط مائلة عند إجبار الأشياء على السلوك المشفر لعنوان url. البديل (لتشفير الخطوط المائلة إلى %2f ) لا معنى له لأن معظم الخوادم ترفض هذه الطلبات تمامًا بسبب مشاكل الأمان حيث لا تستطيع خوادم الواجهة الخلفية عادةً التمييز بين %2f و / في مكون المسار حيث يعمل على ثماني بتات مفككة.

لذا فإن الجزء الوحيد حيث يكون للشرطة المائلة ترميزًا منطقيًا هو في سلاسل الاستعلام وهذا هو المكان الذي يعمل فيه برنامج التشفير المستند إلى dict والذي يعمل فيه urlencode بهذا الشكل. ومع ذلك ، فحتى هناك شرطة مائلة لا يلزم تشفيرها ، لذلك لا يوجد سبب لإجبارها على التشفير.

يجب أن تستخدم الوظيفة urlencode لمعظم الأشخاص بشكل افتراضي وهذا هو السبب في أنها لا تقوم بترميز الشرطة المائلة. إذا كانت لديك متطلبات مخصصة ، فيمكنك تجاوز الوظيفة في تسجيل الفلتر الخاص بك.

نعم. شكرا لك ارمين.

مرحبًا ، لقد واجهت نفس المشكلة مع رفض القطع ، هذا هو الكود:

jinja2.Template ("{{أقراص | رفض ('sameas'، '/') | قائمة}}"). عرض (أقراص = ["/"، "/ mnt / disk0"، "/ mnt / disk1"])
u "['/'، '/ mnt / disk0'، '/ mnt / disk1']"

أريد رفض قرص الجذر ، لكنه لم يعد يعمل ، كيف أحلها؟

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

يعمل لدي.

ما زلت لا تعمل بالنسبة لي ، ThiefMaster ، هل ستصدر مشكلة الثعبان؟ ما هو إصدار Python الذي استخدمته.

    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'

أوه .. sameas يستخدم is (ولا يمكنك توقع عمل 'foo' is 'foo' ). تريد equalto الذي يستخدم == .

نعم إنه يعمل ، أنا لست عائلة مع Jinja2. شكرا ياThiefMaster

لذا فإن الجزء الوحيد حيث يكون للشرطة المائلة ترميزًا منطقيًا في سلاسل الاستعلام وهذا هو المكان الذي يعمل فيه المشفر المستند إلى dict الذي يعمل فيه urlencode على هذا النحو. ومع ذلك ، فحتى هناك شرطة مائلة لا يلزم تشفيرها ، لذلك لا يوجد سبب لإجبارها على التشفير.

لا ، على سبيل المثال تحتاج إلى ترميز / في أسماء المستخدمين وكلمات المرور أيضًا.
انها السبب JS ديه encodeURI __and__ encodeURIComponent .

هذا عادل بما فيه الكفاية ولكن من الناحية العملية ليس من الضروري أن يكون هناك أيضًا ويتم إهمال بيانات الاعتماد المضمنة على أي حال. نظرًا لأنه من غير المحتمل أن يتم إنتاجها داخل القوالب ، فهي حالة متطورة لا تستحق التفكير حقًا.

يستخدم Ansible Jinja ، ومن الشائع جدًا التعامل مع بيانات اعتماد الأمان عند إعداد الأنظمة. لقد وصلت للتو إلى حالة تحتوي فيها كلمة المرور التي تم إنشاؤها تلقائيًا على شرطة مائلة لم يتم استبدالها بـ urlencode لإنشاء عنوان URL لقاعدة البيانات ، وهو أمر مؤسف للغاية. في حين أن كسر السلوك الحالي سيكون مشكلة ، فلماذا لا نقدم مرشحًا ثانيًا لا يفلت من الشرطات المائلة؟

أنسبل يمكن أن تفعل ذلك. ليست هناك حاجة لمثل هذا التغيير في Jinja نفسها - فهو قابل للتوسيع بما يكفي لإضافة مرشحات مخصصة أو حتى استبدال المرشحات المدمجة.

ThiefMaster هل حالات الاستخدام بخلاف إنشاء قوالب HTML ليست ذات صلة عند تحديد ما هو مفيد

danielkza ما الذي يمنع Saltstack من توفير مرشح يقوم بذلك؟

mitsuhiko لماذا تضم ​​Jinja أي مرشحات مدمجة بعد ذلك؟ يمكنني تخمين ذلك فقط لأنها مفيدة في حالات الاستخدام المتعددة. لقد استخدمت Ansible و Salt كمثالين على المكان المرغوب فيه للقدرة على الهروب من الشرطات المائلة في عناوين URL ، وبالتالي ، سيكون من المفيد توفيرها للجميع.

ماذا عن إضافة وسيطة safe إلى urlencode ، كما فعلت Python urllib.url_quote ، بحيث يتم الاحتفاظ بالشرط المائلة افتراضيًا ، ولكن بطريقة يمكن تجاوزها بسهولة؟

تحاول Jinja توفير بعض الوظائف شائعة الاستخدام. لدينا وضعان لتشفير url الذي يوفر لك حوالي 95٪. يمكنك ترميز سلاسل استعلام كاملة عن طريق ترميز dict ويمكنك الترميز إلى مجموعة مشتركة صالحة للمسارات من خلال urlencode على السلاسل.

نحن لا نفعل أي شيء آخر غير utf-8 أو ذلك. لأن أين ستتوقف. هناك أجزاء كثيرة جدًا من عنوان url ، وهناك قزحية وكل منها لديه مكامن الخلل الخاصة به. عندما نكون هناك ، لماذا لا نوفر أيضًا برنامج تشفير Punycode لـ netloc؟

لقد واجهت هذه المشكلة عند محاولة إنشاء ملف في مستودع gitlab عبر مكالمات API. يتطلب gitlab api أن يتم تشفير الشرطات المائلة. لإنجاز هذا العمل ، أقوم بما يلي: {{myvar | urlencode | regex_replace ('/'، '٪ 2F')}}. أنا أعمل مع مرشحات Ansible و Jinja2 في مهام كتاب اللعب الخاصة بي. قد يكون هذا حلاً لأولئك منكم الذين يصلون إلى هذا ، حيث تحققت من أنه يعمل.

أرى بعض الجدل حول ما هي الأحرف التي يجب أن تكون مشفرة في المائة ، على حد علمي ، هذا مغطى حاليًا في RFC3986. https://tools.ietf.org/html/rfc3986#section -2.2

على الرغم من حالة الاستخدام الخاصة بي ، فقد قدم ahuffman عملًا معقولًا.

أريد إغلاق هذا لأنه ظهر مرة أخرى. كانت حججي ضد وجود هذا موجودة بالفعل هنا في وقت سابق ولكني أريد أن أكررها لأن هناك بالفعل علاقات عامة مفتوحة حاليًا (# 864) والتي تقترح إضافة عامل تصفية آخر لها لمساعدة واجهة برمجة تطبيقات GitLab.

تعطلت واجهة برمجة تطبيقات GitLab إذا تم وضعها خلف جميع أنواع إعدادات الوكيل وهناك مشكلات مفتوحة لها ( مثال على المشكلة ). أود بدلاً من ذلك أن أقترح توثيق حل بديل ولماذا لا ينبغي على الناس القيام به.

يمكن أن يكون الحل البديل هو هذا:

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

هذا موقف قليل ولكن القيام بذلك يمكن أن يشجع الناس على عدم تكرار أخطاء الآخرين التي جاءت قبلهم.