설정¶

경고

특히 기본값이 비어 있지 않은 리스트나 사전인 경우(STATICFILES_FINDERS 같은) 설정을 재정의할 때 주의하십시오. 사용하려는 Django 기능에 필요한 구성 요소를 유지하는지 확인하십시오.

코어 설정 ¶

Django 코어에서 사용 가능한 설정 목록과 기본값입니다. 기여 앱에서 제공하는 설정은 아래에 나열되어 있으며, 그 다음에 코어 설정의 주제 색인이 따릅니다. 입문용 자료는 설정 주제 가이드를 참조하십시오.

`ABSOLUTE_URL_OVERRIDES`¶

기본값: {} (빈 사전)

이 사전은 모델 객체를 가져와 해당 URL을 반환하는 함수와 "app_label.model_name" 문자열을 매핑합니다. 이는 설치별로 get_absolute_url() 메서드를 삽입하거나 재정의하는 방법입니다. 예시:

ABSOLUTE_URL_OVERRIDES = {
    "blogs.blog": lambda o: "/blogs/%s/" % o.slug,
    "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

이 설정에서 사용되는 모델 이름은 실제 모델 클래스 이름의 대소문자와 관계없이 모두 소문자여야 합니다.

`ADMINS`¶

기본값: [] (빈 리스트)

코드 오류 알림을 받는 모든 사람의 목록입니다. DEBUG=False 일 때 및 AdminEmailHandler가 (LOGGING에서 기본 설정으로) 구성된 경우, Django는 예외 세부 정보를 이 사람들에게 이메일로 보냅니다.

목록의 각 항목은 (전체 이름, 이메일 주소) 튜플이어야 합니다. 예시:

[("John", "john@example.com"), ("Mary", "mary@example.com")]

`ALLOWED_HOSTS`¶

기본값: [] (빈 리스트)

이 Django 사이트가 제공할 수 있는 호스트/도메인 이름을 나타내는 문자열 목록입니다. 이는 보안 조치로, 보이기에는 안전한 웹 서버 구성에서도 HTTP Host 헤더 공격을 방지합니다.

이 목록의 값은 완전히 정규화된 이름(예: 'www.example.com')일 수 있으며, 이 경우 요청의 Host 헤더와 정확히 일치합니다(대소문자를 구분하지 않고 포트를 제외한 것). 마침표로 시작하는 값은 하위 도메인 와일드카드로 사용할 수 있습니다: '.example.com'은 example.com, www.example.com 및 example.com의 다른 하위 도메인과 일치합니다. '*' 값은 모든 것과 일치합니다. 이 경우, Host 헤더의 유효성 검사를 직접 제공해야 합니다(MIDDLEWARE에서 처음에 이 미들웨어를 사용한다면).

Django는 또한 모든 항목의 완전히 정규화된 도메인 이름(FQDN)을 허용합니다. 일부 브라우저는 Host 헤더에 후행 점을 포함시킬 수 있으며, Django는 호스트 유효성 검사를 수행할 때 이를 제거합니다.

Host 헤더(또는 USE_X_FORWARDED_HOST가 활성화된 경우 X-Forwarded-Host)가 이 목록의 어떤 값과도 일치하지 않으면, django.http.HttpRequest.get_host() 메서드는 SuspiciousOperation을 발생시킵니다.

DEBUG가 True이고 ALLOWED_HOSTS가 비어 있을 때, 호스트는 ['.localhost', '127.0.0.1', '[::1]']과 일치하는지 유효성이 검사됩니다.

이 유효성 검사는 get_host()를 통해 적용됩니다. 코드가 request.META에서 Host 헤더에 직접 액세스하는 경우 이 보안 보호가 무

시됩니다.

`APPEND_SLASH`¶

기본값: True

True로 설정되면, 요청 URL이 URLconf의 패턴과 일치하지 않고 슬래시로 끝나지 않으면 슬래시가 추가된 동일한 URL로 HTTP 리디렉션됩니다. 리디렉션은 POST 요청에서 제출된 데이터를 잃어버릴 수 있습니다.

APPEND_SLASH 설정은 CommonMiddleware이 설치된 경우에만 사용됩니다 (자세한 내용은 미들웨어를 참조). 또한 PREPEND_WWW도 참조하십시오.

`CACHES`¶

기본값:

{
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
    }
}

Django에서 사용할 모든 캐시의 설정을 포함하는 사전입니다. 이는 개별 캐시의 옵션을 포함하는 사전으로 매핑되는 중첩된 사전입니다.

CACHES 설정은 반드시 default 캐시를 구성해야 하며, 추가로 여러 캐시를 정의할 수 있습니다. 로컬 메모리 캐시 이외의 캐시 백엔드를 사용하거나 여러 캐시를 정의해야 하는 경우 추가 옵션이 필요합니다. 다음과 같은 캐시 옵션이 있습니다.

BACKEND¶

기본값: '' (빈 문자열)

사용할 캐시 백엔드입니다. 내장 캐시 백엔드는 다음과 같습니다:

'django.core.cache.backends.db.DatabaseCache'
'django.core.cache.backends.dummy.DummyCache'
'django.core.cache.backends.filebased.FileBasedCache'
'django.core.cache.backends.locmem.LocMemCache'
'django.core.cache.backends.memcached.PyMemcacheCache'
'django.core.cache.backends.memcached.PyLibMCCache'
'django.core.cache.backends.redis.RedisCache'

Django와 함께 제공되지 않는 캐시 백엔드를 사용하려면 BACKEND를 캐시 백엔드 클래스의 완전히 정규화된 경로로 설정하면 됩니다(예: mypackage.backends.whatever.WhateverCache).

KEY_FUNCTION¶

접두어, 버전 및 키를 최종 캐시 키로 어떻게 합성할지를 정의하는 함수(또는 호출 가능한 함수)의 점 경로가 포함된 문자열입니다. 기본 구현은 다음 함수와 동등합니다:

def make_key(key, key_prefix, version):
    return ":".join([key_prefix, str(version), key])

동일한 인수 시그니처를 갖는 한 원하는 어떤 키 함수를 사용할 수 있습니다.

더 많은 정보는 캐시 문서를 참조하십시오.

KEY_PREFIX¶

기본값: '' (빈 문자열)

Django 서버가 사용하는 모든 캐시 키에 자동으로 포함(기본적으로 앞에 붙임)될 문자열입니다.

더 많은 정보는 캐시 문서를 참조하십시오.

LOCATION¶

기본값: '' (빈 문자열)

사용할 캐시의 위치입니다. 이는 파일 시스템 캐시의 디렉토리, memcache 서버의 호스트 및 포트 또는 로컬 메모리 캐시의 식별 이름일 수 있습니다. 예시:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}

OPTIONS¶

기본값: None

캐시 백엔드에 전달할 추가 매개 변수입니다. 사용 가능한 매개 변수는 캐시 백엔드에 따라 다릅니다.

일부 사용 가능한 매개 변수 정보는 캐시 인자 문서에서 찾을 수 있습니다. 자세한 내용은 백엔드 모듈의 문서를 참조하십시오.

TIMEOUT¶

기본값: 300

캐시 항목이 만료되는 시간(초)입니다. 이 설정의 값이 None인 경우, 캐시 항목은 만료되지 않습니다. 값이 0이면 키가 즉시 만료됩니다(사실상 "캐시하지 않음").

VERSION¶

기본값: `1

Django 서버에서 생성된 캐시 키의 기본 버전 번호입니다.

더 많은 정보는 캐시 문서를 참조하십시오.

자료를 받아서 또 다른 문장으로 번역해 드리겠습니다:

`CACHE_MIDDLEWARE_ALIAS`¶

기본값: 'default'

캐시 미들웨어에 사용할 캐시 연결입니다.

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

기본값: '' (빈 문자열)

캐시 미들웨어에 의해 생성된 캐시 키에 접두어로 추가될 문자열입니다. 이 접두어는 KEY_PREFIX 설정과 결합되며, 이를 대체하지 않습니다.

Django의 캐시 프레임워크를 참조하십시오.

`CACHE_MIDDLEWARE_SECONDS`¶

기본값: 600

캐시 미들웨어에 의해 페이지를 캐시할 기본 시간(초)입니다.

Django의 캐시 프레임워크를 참조하십시오.

`CSRF_COOKIE_AGE`¶

기본값: 31449600 (약 1년, 초 단위)

CSRF 쿠키의 수명(초)입니다.

오랜 유효 기간을 설정하는 이유는 사용자가 브라우저를 닫거나 페이지를 북마크한 후 브라우저 캐시에서 해당 페이지를 로드하는 경우의 문제를 피하기 위해서입니다. 지속적인 쿠키 없이는 이러한 경우에 양식 제출이 실패할 수 있습니다.

일부 브라우저(특히 인터넷 익스플로러)는 지속 쿠키의 사용을 허용하지 않거나 디스크에서 쿠키 저장소의 인덱스가 손상될 수 있으므로 CSRF 보호 검사가(때로는 간헐적으로) 실패할 수 있습니다. 이 설정을 None으로 변경하면 세션 기반 CSRF 쿠키를 사용하게 되며, 이 경우 쿠키를 지속 저장소 대신 메모리에 유지합니다.

`CSRF_COOKIE_DOMAIN`¶

기본값: None

CSRF 쿠키를 설정할 때 사용할 도메인입니다. 이는 일반적인 크로스 사이트 요청 위조 보호에서 제외되어야 하는 교차 하위 도메인 요청을 쉽게 허용하기 위해 유용합니다. 이를 위해 문자열로 ".example.com"과 같이 설정하여 한 하위 도메인의 양식에서 다른 하위 도메인으로 제공된 보기에 의해 수락되는 POST 요청을 허용할 수 있습니다.

이 설정의 존재는 Django의 CSRF 보호가 기본적으로 크로스 하위 도메인 공격으로부터 안전하다는 것을 의미하지 않습니다. 자세한 내용은 CSRF 제한 사항 섹션을 참조하십시오.

`CSRF_COOKIE_HTTPONLY`¶

기본값: False

CSRF 쿠키에 HttpOnly 플래그를 사용할지 여부입니다. 이를 True로 설정하면 클라이언트 측 JavaScript에서 CSRF 쿠키에 접근할 수 없습니다.

CSRF 쿠키를 HttpOnly로 지정하는 것은 실제적인 보호를 제공하지 않습니다. 왜냐하면 CSRF는 교차 도메인 공격을 방지하기 위한 것일 뿐이며, 공격자가 JavaScript를 통해 쿠키를 읽을 수 있다면 브라우저가 알기로는 이미 동일한 도메인에 있기 때문에 원하는 대로 할 수 있습니다(XSS가 CSRF보다 훨씬 더 큰 취약점입니다).

이 설정은 실질적인 이점이 거의 없지만, 때때로 보안 감사관들에 의해 필요할 수 있습니다.

이를 활성화하고 AJAX 요청으로 CSRF 토큰의 값을 전송해야 하는 경우, 자바스크립트는 쿠키에서가 아닌 숨겨진 CSRF 토큰 폼 입력에서 값을 가져와야 합니다.

HttpOnly에 대한 자세한 내용은 SESSION_COOKIE_HTTPONLY을 참조하십시오.

`CSRF_COOKIE_MASKED`¶

Django 4.1에서 추가.

기본값: False

CSRF 쿠키를 가리

는지 여부입니다. 사용 방법에 대한 자세한 내용은 릴리스 노트를 참조하십시오.

4.1 버전부터는 사용이 중지됨: 이 전환 설정은 사용이 중지되었으며 Django 5.0에서 제거될 예정입니다.

`CSRF_COOKIE_NAME`¶

기본값: 'csrftoken'

CSRF 인증 토큰에 사용할 쿠키의 이름입니다. 응용 프로그램의 다른 쿠키 이름과 다르게 설정할 수 있습니다. 교차 사이트 요청 위조 보호를 참조하십시오.

`CSRF_COOKIE_PATH`¶

기본값: '/

CSRF 쿠키에 설정된 경로입니다. 이는 Django 설치의 URL 경로와 일치하거나 해당 경로의 상위 경로여야 합니다.

동일한 호스트명 아래에서 여러 개의 Django 인스턴스가 실행되는 경우 유용합니다. 이들은 서로 다른 쿠키 경로를 사용할 수 있으며, 각 인스턴스는 자체 CSRF 쿠키만 볼 수 있습니다.

`CSRF_COOKIE_SAMESITE`¶

기본값: 'Lax'

CSRF 쿠키의 SameSite 플래그의 값입니다. 이 플래그는 쿠키가 교차 사이트 요청에서 전송되지 않도록 합니다.

SESSION_COOKIE_SAMESITE에 대한 자세한 내용은 SameSite를 참조하십시오.

`CSRF_COOKIE_SECURE`¶

기본값: False

CSRF 쿠키에 보안 쿠키를 사용할지 여부입니다. 이를 True로 설정하면 쿠키가 "보안"으로 표시되며, 브라우저는 쿠키가 HTTPS 연결로만 전송되도록 할 수 있습니다.

`CSRF_USE_SESSIONS`¶

기본값: False

CSRF 토큰을 쿠키가 아닌 사용자 세션에 저장할지 여부입니다. 이는 django.contrib.sessions의 사용을 필요로 합니다.

쿠키에 CSRF 토큰을 저장하는 것(기본 설정)은 안전하지만, 다른 웹 프레임워크에서 일반적으로 사용되는 세션에 저장하는 것이 일반적인 관행이므로 보안 감사관들에 의해 때때로 요구될 수 있습니다.

기본 오류 뷰는 CSRF 토큰을 필요로 하므로, CSRF_USE_SESSIONS를 사용하는 경우 SessionMiddleware는 오류 뷰를 트리거할 수 있는 예외를 발생시키는 모든 미들웨어보다 MIDDLEWARE에 먼저 나와야 합니다. 미들웨어 순서를 참조하십시오.

`CSRF_FAILURE_VIEW`¶

기본값: 'django.views.csrf.csrf_failure'

CSRF 보호에 의해 들어오는 요청이 거부될 때 사용될 보기 함수의 점 경로입니다. 이 함수는 다음 형식을 가져야 합니다:

def csrf_failure(request, reason=""):
    ...

여기서 reason은 요청이 거부된 이유를 나타내는 짧은 메시지(개발자나 로깅을 위한 것이며 최종 사용자를 위한 것이 아님)입니다. 이 함수는 HttpResponseForbidden를 반환해야 합니다.

django.views.csrf.csrf_failure() 함수는 기본적으로 '403_csrf.html' 템플릿을 렌더링하는 데 사용되는 template_name 매개변수를 추가로 받습니다. 해당 이름의 템플릿이 있는 경우 해당 템플릿이 사용됩니다.

`CSRF_HEADER_NAME`¶

기본값: 'HTTP_X_CSRFTOKEN'

CSRF 인증에 사용되는 요청 헤더의 이름입니다.

request.META의 다른 HTTP 헤더와 마찬가지로 서버로부터 수신한 헤더 이름은 대문자로 변환되며 모든 문자가 대문자로 변환되며 모든 하이픈이 밑줄로 바뀌며 이름에 HTTP_ 접두어가 추가됩니다. 예를 들어 클라이언트가 X-XSRF-TOKEN 헤더를 보낸 경우, 설정은

'HTTP_X_XSRF_TOKEN'이어야 합니다.

`CSRF_TRUSTED_ORIGINS`¶

기본값: [] (빈 목록)

안전하지 않은 요청(예: POST)을 위한 신뢰할 수 있는 원본 목록입니다.

Origin 헤더를 포함하는 요청의 경우 Django의 CSRF 보호는 해당 헤더가 Host 헤더에 있는 원본과 일치해야 합니다.

Origin 헤더를 포함하지 않는 안전한 요청인 경우 요청에는 Host 헤더에 있는 원본과 일치하는 Referer 헤더가 있어야 합니다.

이러한 검사를 통해 예를 들어 subdomain.example.com의 POST 요청이 api.example.com에 성공하지 못하도록 방지합니다. 교차 출처 안전하지 않은 요청이 필요한 경우 위의 예제를 계속 진행하여 이 목록에 'https://subdomain.example.com'를 추가하면 됩니다(안전하지 않은 페이지에서 요청이 시작되는 경우 http://...도 추가해야 함).

이 설정은 서브도메인도 지원하므로 '* 예제.com'과 같이 지정하여 example.com의 모든 서브도메인에서 액세스를 허용할 수 있습니다.

hwisaac

다음 포스트

Django: settings(1)

djnago-setting

설정¶

코어 설정 ¶

`ABSOLUTE_URL_OVERRIDES`¶

`ADMINS`¶

`ALLOWED_HOSTS`¶

`APPEND_SLASH`¶

`CACHES`¶

`CACHE_MIDDLEWARE_ALIAS`¶

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

`CACHE_MIDDLEWARE_SECONDS`¶

`CSRF_COOKIE_AGE`¶

`CSRF_COOKIE_DOMAIN`¶

`CSRF_COOKIE_HTTPONLY`¶

`CSRF_COOKIE_MASKED`¶

`CSRF_COOKIE_NAME`¶

`CSRF_COOKIE_PATH`¶

`CSRF_COOKIE_SAMESITE`¶

`CSRF_COOKIE_SECURE`¶

`CSRF_USE_SESSIONS`¶

`CSRF_FAILURE_VIEW`¶

`CSRF_HEADER_NAME`¶

`CSRF_TRUSTED_ORIGINS`¶

django-settings(2)-database

0개의 댓글

Django: settings(1)

djnago-setting

설정¶

코어 설정¶

ABSOLUTE_URL_OVERRIDES¶

ADMINS¶

ALLOWED_HOSTS¶

APPEND_SLASH¶

CACHES¶

CACHE_MIDDLEWARE_ALIAS¶

CACHE_MIDDLEWARE_KEY_PREFIX¶

CACHE_MIDDLEWARE_SECONDS¶

CSRF_COOKIE_AGE¶

CSRF_COOKIE_DOMAIN¶

CSRF_COOKIE_HTTPONLY¶

CSRF_COOKIE_MASKED¶

CSRF_COOKIE_NAME¶

CSRF_COOKIE_PATH¶

CSRF_COOKIE_SAMESITE¶

CSRF_COOKIE_SECURE¶

CSRF_USE_SESSIONS¶

CSRF_FAILURE_VIEW¶

CSRF_HEADER_NAME¶

CSRF_TRUSTED_ORIGINS¶

django-settings(2)-database

0개의 댓글

코어 설정 ¶

`ABSOLUTE_URL_OVERRIDES`¶

`ADMINS`¶

`ALLOWED_HOSTS`¶

`APPEND_SLASH`¶

`CACHES`¶

`CACHE_MIDDLEWARE_ALIAS`¶

`CACHE_MIDDLEWARE_KEY_PREFIX`¶

`CACHE_MIDDLEWARE_SECONDS`¶

`CSRF_COOKIE_AGE`¶

`CSRF_COOKIE_DOMAIN`¶

`CSRF_COOKIE_HTTPONLY`¶

`CSRF_COOKIE_MASKED`¶

`CSRF_COOKIE_NAME`¶

`CSRF_COOKIE_PATH`¶

`CSRF_COOKIE_SAMESITE`¶

`CSRF_COOKIE_SECURE`¶

`CSRF_USE_SESSIONS`¶

`CSRF_FAILURE_VIEW`¶

`CSRF_HEADER_NAME`¶

`CSRF_TRUSTED_ORIGINS`¶