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/ 와 같은 도구는 이러한 방식으로 작동합니다. 또한 이스케이프 처리된 슬래시가 있는 GET 요청 내부에 URL이 전달될 것으로 예상하는 회사 내부에 하나 이상의 도구가 있습니다.
또한, 나는 이해하지 않는 이유 unicode_urlencode 라는 내부 do_urlencode 와 for_qs=True .
제가 뭔가 잘못 이해하고 있는 것일 수도 있습니다.

슬래시는 경로 구성 요소의 예약된 문자이며 더 일반적인 동작은 URL 인코딩 동작을 강제할 때 슬래시를 제외한 모든 것을 인코딩하는 것입니다. (슬래시를 %2f 로 인코딩하는) 대안은 백엔드 서버가 일반적으로 %2f 및 / 를 구별할 수 없기 때문에 보안 문제로 인해 대부분의 서버가 이러한 요청을 완전히 거부하기 때문에 의미가 없습니다. 디코딩된 옥텟에서 작동할 때 경로 구성 요소.

따라서 슬래시가 실제로 인코딩이 의미가 있는 유일한 부분은 쿼리 문자열에 있으며 여기에서 urlencode 의 dict 기반 인코더가 그렇게 작동합니다. 그러나 슬래시가 있어도 인코딩할 필요가 없으므로 인코딩을 강제할 이유가 없습니다.

urlencode 함수는 기본적으로 대부분의 사람들에게 사용해야 하므로 슬래시를 인코딩하지 않습니다. 사용자 정의 요구 사항이 있는 경우 필터 등록에서 기능을 재정의할 수 있습니다.

확인. 아르민 감사합니다.

안녕하세요, 슬래시 거부와 동일한 문제가 발생했습니다. 코드는 다음과 같습니다.

jinja2.Template("{{ 디스크|거부('sameas', '/')|목록 }}").render(disks=["/", "/mnt/disk0", "/mnt/disk1"])
유"['/', '/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 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 감사합니다.

따라서 슬래시가 실제로 의미 있는 인코딩이 되는 유일한 부분은 쿼리 문자열에 있으며 urlencode가 가지고 있는 dict 기반 인코더가 그렇게 작동하는 곳입니다. 그러나 슬래시가 있어도 인코딩할 필요가 없으므로 인코딩을 강제할 이유가 없습니다.

아니요, 예를 들어 사용자 이름과 비밀번호에도 / 를 인코딩해야 합니다.
이것이 JS에 encodeURI __and__ encodeURIComponent 가 있는 이유입니다.

그것은 충분히 공평하지만 실제로는 필요하지 않으며 포함 된 자격 증명은 어쨌든 사용되지 않습니다. 템플릿 내에서 생성될 가능성이 낮기 때문에 실제로 고려할 가치가 없는 경우입니다.

Ansible은 Jinja를 사용하며 시스템을 설정할 때 보안 자격 증명을 처리하는 것이 일반적입니다. 방금 자동으로 생성된 비밀번호에 슬래시가 포함되어 있는데 이 슬래시는 데이터베이스 URL을 생성하기 위해 urlencode 로 대체되지 않은 경우입니다. 이는 매우 불행한 일입니다. 현재 동작을 깨는 것이 문제가 될 수 있지만 슬래시를 이스케이프하지 않는 두 번째 필터를 도입하지 않겠습니까?

앤서블은 그렇게 할 수 있습니다. Jinja 자체에는 그러한 변경이 필요하지 않습니다. 사용자 정의 필터를 추가하거나 내장 필터를 교체할 수 있을 정도로 충분히 확장 가능합니다.

@ThiefMaster Jinja 자체에 포함하는 것이 유용한지 결정할 때 HTML 템플릿을 구성하는 것 이외의 사용 사례는 관련이 없습니까? 예를 들어, Ansible과 유사한 목적을 가진 Saltstack 프로젝트도 템플릿에 Jinja를 사용하며 동일한 변경의 이점을 얻을 수 있습니다.

@danielkza saltstack 이 필터를 제공하는 것을

@mitsuhiko 왜 Jinja에 내장 필터가 포함되어 있습니까? 여러 사용 사례에서 유용하기 때문이라고 추측할 수 있습니다. URL에서 슬래시를 이스케이프할 수 있는 것이 바람직한 두 가지 예로 Ansible과 Salt를 사용했습니다. 따라서 모든 사람이 사용할 수 있도록 하는 것이 중요합니다.

safe 인수를 urlencode 에 추가하는 것은 Python의 urllib.url_quote 처럼 기본적으로 슬래시가 유지되지만 쉽게 무시할 수 있는 방식으로 추가하는 것입니다.

Jinja는 일반적으로 사용되는 몇 가지 기능을 제공하려고 합니다. 약 95%를 얻을 수 있는 urlencoding을 위한 두 가지 모드가 있습니다. 사전을 인코딩하여 전체 쿼리 문자열을 인코딩할 수 있으며 문자열의 urlencode를 통한 경로에 유효한 공통 집합으로 인코딩할 수 있습니다.

우리는 utf-8이나 그 외에는 아무것도 하지 않습니다. 어디에서 멈출 것이기 때문입니다. URL에 너무 많은 부분이 있고 홍채가 있으며 모두 고유한 꼬임이 있습니다. 우리가 거기에 있을 때 netloc용 퓨니코드 인코더도 제공하지 않는 이유는 무엇입니까?

API 호출을 통해 gitlab 리포지토리에 파일을 만들려고 할 때 이 문제가 발생했습니다. gitlab API를 사용하려면 슬래시를 인코딩해야 합니다. 이 작업을 수행하려면 다음을 수행합니다. {{ myvar | urlencode | regex_replace('/','%2F') }}. 플레이북 작업에서 Ansible 및 Jinja2 필터로 작업하고 있습니다. 이것은 내가 작동하는 것을 확인했기 때문에 이것을 치는 사람들을 위한 해결 방법이 될 수 있습니다.

어떤 문자를 백분율로 인코딩해야 하는지에 대한 약간의 논쟁이 있습니다. 이 내용은 현재 RFC3986에서 다루고 있습니다. https://tools.ietf.org/html/rfc3986#section -2.2

내 사용 사례의 경우 @ahuffman 이 합리적인 해결 방법을 제공했습니다.

또 나왔으니까 닫고 싶어요. 이것에 대한 나의 주장은 이미 여기에서 이미 언급되었지만 GitLab의 API에 도움이 되도록 다른 필터를 추가할 것을 제안하는 현재 PR이 열려 있기 때문에 다시 강조하고 싶습니다(#864).

모든 종류의 프록시 설정 뒤에 배치되고 이에 대해 열려 있는 문제가 있는 경우 GitLab의 API가 손상되었습니다( 예제 문제 ). 대신 해결 방법과 사람들이 하지 말아야 하는 이유를 문서화할 것을 제안합니다.

해결 방법의 예는 다음과 같습니다.

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

이것은 약간의 입장을 취하는 것이지만 이렇게 하면 사람들이 이전에 있었던 다른 사람들의 실수를 반복하지 않도록 격려할 수 있습니다.