도장고 9편-----템플릿에 대한 고급화두--전반편

카탈로그
RequestContext 및 컨텍스트 프로세서
 auth
debug
i18n
media
static
csrf
request
messages
HTML 자동 이스케이프
단일 변수에서 비활성화
템플릿의 블록에서 비활성화
RequestContext 및 컨텍스트 프로세서
먼저 앞서 설명한 몇 가지 용어를 살펴보겠습니다.
• 템플릿은 문서 또는 일반 Python 문자열이며 Django 템플릿 언어로 표시됩니다.템플릿에는 템플릿 레이블과 변수가 있습니다.템플릿 라벨은 템플릿의 기호로 특정한 일을 하는 데 쓰인다.이런 정의는 상당히 난해하다.예를 들어 템플릿 탭은 내용을 생성하거나 제어 구조(if 문장이나 for 순환)로 사용하거나 데이터베이스에서 내용을 가져오거나 다른 템플릿 탭에 접근할 수 있다.템플릿 레이블을 {%와%} 사이에 두려면 다음과 같이 하십시오.

{% if is_logged_in %}
Thanks for logging in!
{% else %}
Please log in.
{% endif %}

• 변수는 값을 출력하는 데 사용되는 템플릿의 기호이기도 합니다.변수를 {{{및}} 사이에 둡니다. My first name is {{first name}.My last name is {{ last_name }}. • 컨텍스트는 템플릿에 전달되는 이름 값 매핑(Python 사전과 유사)입니다. •템플릿이 컨텍스트를 렌더링하는 절차는 변수가 있는 위치를 컨텍스트의 값으로 대체하고 모든 템플릿 레이블을 실행하는 것입니다.
다음 두 가지 뷰를 보겠습니다.

from django.template import loader, Context
def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am view 1.'
    })
    return t.render(c
def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am the second view.'
    })
    return t.render(c)

이 두 보기에서 우리는 템플릿에 같은 세 가지 변수를 전달했다: app,user,ipaddress .이런 중복을 없애는 게 낫지 않을까요?이러한 문제를 해결하기 위해 RequestContext와 컨텍스트 프로세서가 사용됩니다.상하문 프로세서는 각 상하문에 자동으로 설정된 변수를 지정하는 데 사용되며,render () 를 호출할 때마다 지정할 필요가 없습니다.이렇게 하려면 템플릿을 렌더링할 때 Context를 RequestContext로 변경합니다.컨텍스트 프로세서의 가장 낮은 레벨을 사용하는 방법은 일부 프로세서를 만들어서 RequestContext에 전달하는 것입니다.컨텍스트 프로세서를 사용하여 위의 예제에서 얻은 코드를 덮어씁니다.

from django.template import loader, RequestContext
def custom_proc(request):
    #         ，   'app'、'user'   'ip_address'
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }
def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = RequestContext(request,
                        {'message': 'I am view 1.'},
                        processors=[custom_proc])
    return t.render(c)
def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = RequestContext(request,
                        {'message': 'I am the second view.'},
                        processors=[custom_proc])
    return t.render(c)

다음은 이 코드를 분석해 보겠습니다.
• 우선 함수custom 정의proc .이것은 상하문 프로세서입니다. 이 프로세서의 매개 변수는 HttpRequest 대상이고, 반환 값은 템플릿 상하문에 사용할 변수를 포함하는 사전입니다.이렇게 간단해요.우리는 그 두 개의 보기 함수를 수정해서 Context를 Request Context로 바꾸었다.이런 상하문을 구축하는 방식은 두 가지가 다르다. 첫째, RequestContext는 첫 번째 파라미터가 반드시 HttpRequest 대상, 즉 보기 함수에 전달되는 파라미터(request)가 되어야 한다고 요구한다.둘째, RequestContext는 선택할 수 있는 프로세스 ors 파라미터를 받아들인다. 그 값은 상하문 프로세서 목록이나 모듈이다.여기, 우리가 전송한 것은 앞에서 정의한 그 프로세서customproc . • 현재, 각 보기는 상하문을 구축할 때 app,user 또는 ip 를 포함하지 않아도 됩니다.address, 왜냐하면customproc가 이미 제공되었습니다.필요한 경우 뷰에서 추가 템플릿 변수를 제공할 수 있습니다.두 보기에 서로 다른 메시지 템플릿 변수를 설정합니다.
상하문 프로세서의 저층 작업 방식을 설명하기 위해서 상술한 예는render () 단축키를 사용하지 않았습니다.하지만 상하문 프로세서를 사용할 때는 이렇게 할 수 있고, 이렇게 하는 것도 추천합니다.이렇게 하려면 contextinstance 매개 변수는 다음과 같다.

from django.shortcuts import render
from django.template import RequestContext
def custom_proc(request):
    #         ，   'app'、'user'   'ip_address'
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }
def view_1(request):
    # ...
    return render(request, 'template1.html',
                  {'message': 'I am view 1.'},
                  context_instance=RequestContext(request, processors=[custom_proc])
                   )
def view_2(request):
    # ...
    return render(request, 'template2.html',
                {'message': 'I am the second view.'},
                context_instance=RequestContext(request, processors=[custom_proc])
                )

데이터 (템플릿 변수) 의 중복을 제거했지만, 코드 (processors를 호출하는 코드) 의 중복을 추가했습니다.
만약 매번 프로세스 ors를 입력해야 한다면, 상하문 프로세서를 사용하면 많은 것을 절약할 수 없다.이에 따라 Django는 전역 컨텍스트 프로세서를 제공합니다.context_processors 설정 (settings.py 파일에서) 은 RequestContext에 항상 제공되는 상하문 프로세서를 가리킨다.그러면 RequestContext를 사용할 때마다 processors 매개 변수를 지정하지 않아도 됩니다.

'context_processors': [
    'django.template.context_processors.debug',
    'django.template.context_processors.request',
    'django.contrib.auth.context_processors.auth',
    'django.contrib.messages.context_processors.messages',
],

이것은 호출 가능한 대상 목록입니다. 인터페이스와 앞에서 정의한customproc 함수와 마찬가지로 매개 변수는 요청 대상이고, 반환 값은 사전이며, 상하문에 통합할 변수를 포함한다.참고, contextprocessors의 값은 문자열이기 때문에 프로세서가 Python 경로에 있어야 합니다. (설정에서 인용할 수 있습니다.)
지정된 각 프로세서는 순서대로 운용된다.따라서 하나의 프로세서가 상하문에 변수를 추가하고, 뒤의 프로세서가 같은 이름의 변수를 추가하면, 뒤의 프로세서가 앞의 변수를 덮어씁니다.Django는 기본적으로 사용되는 몇 개의 간단한 상하문 프로세서를 제공합니다.아래의 몇 마디 소절에서 상세하게 서술하다.
 auth
django.contrib.auth.context_processors.auth에서 이 프로세서를 사용하면 RequestContext에 다음 변수가 포함됩니다: • user: auth.현재 로그인한 사용자를 나타내는 User 인스턴스(로그인하지 않은 경우 AnonymousUser 인스턴스)•perms : django.contrib.auth.context_processors.PermWrapper 인스턴스는 현재 로그인한 사용자가 소유한 권한을 나타냅니다.
debug
django.template.context_processors.debug에서 이 프로세서를 사용하면 RequestContext에 다음 두 변수가 포함되어 있지만, 전제는 DEBUG가 설정한 값이 True이고 INTER-NAL 이다.IPS 설정에 요청한 IP 주소(request.META['REMOTE ADDR']): • debug:True.템플릿에서 DEBUG 모드 여부를 테스트할 수 있습니다. •sql_queries: {'sql':...,'time':...} 사전으로 구성된 목록은 요청을 처리하는 과정에서 실행된 SQL 조회와 사용 시간을 나타냅니다.목록의 값은 조회의 실행 순서에 따라 배열되며, 방문할 때 불활성 생성
i18n
django.template.context_processors.i18n에서 이 프로세서를 사용하면 RequestContext에는 • LANGUAGES: LANGUAGES에서 설정한 값 •LANGUAGE_CODE: request.LANGUAGE_CODE가 존재하고 값을 반환합니다.그렇지 않으면 LANGUAGE 로 돌아갑니다.CODE 설정의 값입니다.
media
django.template.context_processors.media에서 이 프로세서를 사용하면 RequestContext에 MEDIA 가 포함됩니다.URL 변수, MEDIA 제공URL 설정의 값입니다.
static
django.template.context_processors.static에서 이 프로세서를 사용하면 RequestContext에 STATIC 가 포함됩니다.URL 변수, STATIC 제공URL 설정의 값입니다.
csrf
django.template.context_processors.csrf 이 프로세서에 영패를 추가하여 csrftoken 템플릿 라벨 사용, 크로스 사이트 요청 위조 방지
request
django.template.context_processors.Request가 이 프로세서를 사용하면 RequestContext에 Request 변수가 포함되어 있으며 현재 HttpRequest 대상입니다.
messages
django.contrib.messages.context_processors.이 프로세서를 사용하면 RequestContext에 다음 두 변수가 포함됩니다: • 메시지: 메시지 프레임워크에 설정된 메시지 목록 (안에 있는 값은 문자열).DEFAULT_MESSAGE_LEVELS: 메시지 레벨 이름이 숫자 값에 매핑됩니다.
HTML 자동 이스케이프
템플릿을 사용하여 HTML을 생성할 때 변수의 값에 특수 문자가 포함되어 HTML에 영향을 미칠 수 있습니다.다음 템플릿 세션에 대해 말하자면

alert('hello')

템플릿을 렌더링한 결과는 다음과 같습니다.

Hello, alert('hello')

따라서 브라우저에서 대화 상자가 나타납니다.
이러한 보안 취약점을 크로스 사이트 스크립트 공격(Cross Site Scripting, XSS)이라고 하는데, 이러한 취약점을 피하기 위해 두 가지 선택이 있습니다. 1.모든 신뢰할 수 없는 변수는 escape 필터에 전송되어 잠재적인 피해가 있는 HTML 문자를 무해한 것으로 변환합니다.Django는 처음 몇 년 동안 기본적으로 이런 방안을 사용했다. 문제는 개발자나 템플릿 작성자에게 책임을 강요하는 것이다. 모든 것을 전의하는 것을 확보해야 한다.하지만 전의 데이터를 잊는 것은 일상적인 일이다.2. Django의 자동 이스케이프 HTML 특성을 사용합니다.
이 동작은 기본적으로 활성화되어 있습니다.만약 Django의 템플릿 시스템을 사용한다면 이 조치의 보호를 받을 수 있다.
단일 변수에서 비활성화
단일 변수에서 자동 이스케이프를 비활성화하려면 safe 필터를 사용합니다.

This will be escaped: {{ data }}
This will not be escaped: {{ data|safe }}

이 필터의 역할은'전의 없이 안심하고 사용할 수 있다'또는'HTML로 안전하게 해석할 수 있다'로 이해할 수 있다.여기에 '' 데이터가 포함되어 있는 경우 결과는 다음과 같습니다.

This will be escaped: <b>
This will not be escaped: 

템플릿의 블록에서 비활성화
템플릿에서 자동 이스케이프 동작을 제어하려면 autoescape 탭에 템플릿(또는 일부)을 넣습니다.

{% autoescape off %}
Hello {{ name }}
{% endautoescape %}

autoescape 탭의 매개 변수는 on 또는off입니다.off는 닫는 것입니다. 때로는 강제 자동 전환이 필요하고, 때로는 사용하지 않으려고 합니다.예를 들면 다음과 같습니다.

Auto-escaping is on by default. Hello {{ name }}
{% autoescape off %}
    This will not be auto-escaped: {{ data }}.
    Nor this: {{ other_data }}
    {% autoescape on %}
        Auto-escaping applies again: {{ name }}
    {% endautoescape %}
{% endautoescape %}