Django 세션 사용하기 ((How to use sessions))

원문 : https://docs.djangoproject.com/en/1.11/topics/http/sessions/

Django는 익명 세션을 완벽하게 지원합니다. 세션 프레임워크를 사용하면 사이트 방문자별로 임의의 데이터를 저장하고 검색 할 수 있습니다. 서버 측에 데이터를 저장하고 쿠키 송수신을 추상화합니다. 쿠키에는 세션 ID가 들어 있지만 데이터 자체는 아닙니다. (쿠키 기반 백엔드를 사용하지 않는 한)
¹⁾

²⁾

세션은 미들웨어를 통해 구현됩니다.³⁾

세션 기능을 사용하려면 다음을 수행하십시오.
⁴⁾

• `MIDDLEWARE` 설정하고 포함되어 있는지 확인하십시오.
  ⁵⁾
  
• django.contrib.sessions.middleware.SessionMiddleware에 의해 만들어진 settings.py 기본 설정 django-admin startproject는 SessionMiddleware를 활성화했습니다.
  ⁶⁾

세션을 사용하고 싶지 않은 경우에는 `MIDDLEWARE`에서 'SessionMiddlewareline '을 삭제하고 `INSTALLED_APPS`에서는 'django.contrib.sessions'를 삭제할 수 있습니다. 약간의 오버 헤드를 줄일 수 있습니다.
⁷⁾

⁸⁾

기본적으로 Django는 데이터베이스에 세션을 저장합니다 (모델 django.contrib.sessions.models.Session ). 이 설정은 편리하지만 일부 설정에서는 세션 데이터를 다른 곳에 저장하는 것이 더 빠르기 때문에 파일 시스템이나 캐시에 세션 데이터를 저장하도록 Django를 구성 할 수 있습니다.
⁹⁾

¹⁰⁾

데이터베이스 기반 세션을 사용하려면 django.contrib.sessions를 `INSTALLED_APPS`에 추가해야합니다.
¹¹⁾

설치를 구성한 후에는manage.pymigrate를 실행하여 세션 데이터를 저장하는 단일 데이터베이스 테이블을 설치하십시오.
¹²⁾

¹³⁾

성능 향상을 위해 캐시 기반 세션 백엔드를 사용할 수 있습니다.
¹⁴⁾

Django의 캐시 시스템을 사용하여 세션 데이터를 저장하려면 먼저 캐시를 구성했는지 확인해야합니다. 자세한 내용은 cache documentation를 참조하십시오.
¹⁵⁾

CACHES에 정의 된 캐시가 여러 개인 경우 Django는 기본 캐시를 사용합니다. 다른 캐시를 사용하려면 해당 캐시의 이름을 `SESSION_CACHE_ALIAS`로 설정하십시오.
¹⁷⁾

캐시가 구성되면 캐시에 데이터를 저장하는 방법에 대해 두 가지 선택 사항이 있습니다.
¹⁸⁾

• `SESSION_ENGINE`
  에 django.contrib.sessions.backends.cache을 설정합니다. 간단한 캐싱 세션 저장소. 세션 데이터는 캐시에 직접 저장됩니다. 그러나 세션 데이터가 지속되지 않을 수 있습니다. 캐시가 가득 차거나 캐시 서버가 다시 시작되면 캐시 된 데이터가 제거 될 수 있습니다.
  ¹⁹⁾
  
• 지속적이고 캐시 된 데이터의 경우 `SESSION_ENGINE`에
  django.contrib.sessions.backends.cached_db을 설정합니다. 이것은 연속 기입 캐시를 사용합니다. 캐시에 대한 모든 쓰기도 데이터베이스에 기록됩니다. 세션 읽기는 데이터가 캐시에없는 경우에만 데이터베이스를 사용합니다.
  ²⁰⁾

두 세션 저장소는 모두 빠르지 만 지속성을 무시하기 때문에 단순한 캐시가 빠릅니다. 대부분의 경우,cached_db 백엔드는 충분히 빠르지 만 성능의 마지막 비트가 필요하고 때때로 세션 데이터를 소멸 시키려고한다면 cache 백엔드가 당신을위한 것입니다.
²¹⁾

cached_db 세션 백엔드를 사용한다면, 데이터베이스 기반 세션 사용하기에 대한 설정 지시 사항을 따라야합니다.
²²⁾

²³⁾

파일 기반 세션을 사용하려면 `SESSION_ENGINE` 설정에 django.contrib.sessions.backends.file을 설정합니다.
²⁴⁾

`SESSION_FILE_PATH` 설정을 원할 수도 있습니다 (기본값은 tempfile.gettempdir (), 가장 가능성있는 /tmp)를 사용하여 Django가 세션 파일을 저장하는 위치를 제어 할 수 있습니다. 웹서버의 위치를 읽고 쓸 수있는 권한이 있는지 확인하십시오.
²⁵⁾

²⁶⁾

쿠키 기반 세션을 사용하려면 `SESSION_ENGINE`에 django.contrib.sessions.backends.signed_cookies을 설정하십시오. 세션 데이터는 Django의 암호화 서명 및 `SECRET_KEY` 도구를 사용하여 저장됩니다.
²⁷⁾

³⁹⁾

SessionMiddleware가 활성화되면 각각의 `HttpRequest` 객체 - Django 뷰의 첫 번째 인수 함수 - 사전과 같은 객체인 '세션'속성을 갖습니다.
⁴⁰⁾

당신은 당신의 관점에서 그것을 읽고 request.session에 쓸 수 있습니다. 여러 번 편집 할 수 있습니다.
⁴¹⁾

이것은 모든 세션 객체의 기본 클래스입니다. 다음과 같은 표준 사전 방법이 있습니다.
⁴²⁾

snippet.python

Example: fav_color=request.session['fav_color']

snippet.python

Example: request.session['fav_color']='blue'

snippet.python

Example: del request.session['fav_color']. 

주어진 키가 이미 세션에없는 경우 이것은 KeyError를 발생시킵니다.
⁴³⁾

snippet.python

Example: 'fav_color' in request.session

snippet.python

Example: fav_color=request.session.get('fav_color','red')

snippet.python

Example: fav_color=request.session.pop('fav_color','blue')

또한 다음과 같은 방법이 있습니다.⁴⁴⁾

세션에서 현재 세션 데이터를 삭제하고 세션 쿠키를 삭제합니다. 이것은 사용자의 브라우저에서 이전 세션 데이터에 다시 액세스 할 수 없도록 하려는 경우에 사용됩니다 (예 : `django.contrib.auth.logout()` 함수를 호출합니다.
⁴⁵⁾

테스트 쿠키를 설정하여 사용자 브라우저가 쿠키를 지원하는지 여부를 결정합니다. 쿠키가 작동하는 방식 때문에 사용자가 다음 페이지 요청을 할 때까지이를 테스트 할 수 없습니다. 자세한 내용은 아래의 테스트 쿠키 설정을 참조하십시오.
⁴⁶⁾

사용자 브라우저가 테스트 쿠키를 수락했는지 여부에 따라 True또는False를 반환합니다. 쿠키가 작동하는 방식 때문에 이전의 별도의 페이지 요청에서 set_test_cookie ()를 호출해야합니다. 자세한 내용은 아래의 테스트 쿠키 설정을 참조하십시오.
⁴⁷⁾

테스트 쿠키를 삭제합니다. 이것을 사용하여 자신을 정리하십시오.
⁴⁸⁾

세션의 만기 시간을 설정합니다. 다양한 값을 전달할 수 있습니다.
⁴⁹⁾

• 만약 value가 정수이면 몇 초 동안 활동하지 않으면 세션이 만료됩니다. 예를 들어, 호출
  request.session.set_expiry (300)를 호출하면 5분 안에 세션이 만료됩니다.
  ⁵⁰⁾
  
• value가 datetime 또는timedelta 객체라면, 세션은 그 특정 날짜/시간에 만료 될 것입니다. PickleSerializer를 사용하는 경우 datetime과timedelta 값은 직렬화 가능합니다.
  ⁵¹⁾
  
• value가 0이면 사용자의 웹 브라우저가 닫힐 때 세션 쿠키가 만료됩니다.
  ⁵²⁾
  
• value가 None이면, 세션은 전역 세션 만료 정책을 사용하는 것으로 되돌아갑니다.
  ⁵³⁾

세션 읽기는 만료 목적의 활동으로 간주되지 않습니다. 세션 만료는 세션이 마지막으로 수정 된 시간부터 계산됩니다.
⁵⁴⁾

이 세션이 만료 할 때까지의 초 수를 반환합니다. 사용자 정의 만료가없는 세션 (또는 브라우저 닫기에서 만료되도록 설정 한 세션)의 경우이 값은 `SESSION_COOKIE_AGE`와 같습니다.
⁵⁵⁾

이 함수는 두 개의 선택적 키워드 인수를 허용합니다.
⁵⁶⁾

• modification : 세션의 마지막 수정으로서 `datetime` 객체입니다. 기본값은 현재 시간입니다.
  ⁵⁷⁾
  
• expiry : 세션의 만기 정보 `datetime` 객체,
  `int` (초 단위) 또는
  'None'. 기본값은 `set_expiry()`에 의해 세션에 저장된 값입니다. 하나가 있거나 'None'.
  ⁵⁸⁾

이 세션이 기한 마감일을 반환합니다. 사용자 정의 만료가없는 세션 (또는 브라우저 닫기에서 만료되도록 설정 한 세션)의 경우이 값은 `SESSION_COOKIE_AGE` 지금부터 날짜 초와 같습니다.
⁵⁹⁾

이 함수는 get_expiry_age()와 동일한 키워드 인수를 받습니다
⁶⁰⁾

사용자의 웹 브라우저가 닫힐 때 세션 쿠키가 만료되는지 여부에 따라 True 또는 False를 반환합니다.
⁶¹⁾

만료 된 세션을 세션 저장소에서 제거합니다. 이 클래스 메소드는 `clearsessions`에 의해 호출됩니다.
⁶²⁾

현재 세션 데이터를 유지하면서 새 세션 키를 만듭니다. `django.contrib.auth.login ()`은 세션 고정에 대한 완화를 위해이 메소드를 호출합니다.
⁶³⁾

⁶⁴⁾

기본적으로 장고는 JSON을 사용하여 세션 데이터를 직렬화합니다. `SESSION_SERIALIZER` 설정을 사용하여 세션 직렬화 형식을 사용자 정의 할 수 있습니다.
⁶⁵⁾

[자신의 시리얼 라이저 작성] (https://docs.djangoproject.com/en/1.11/topics/http/sessions/#custom-serializers)에 설명 된주의 사항이 있더라도 JSON 직렬화를 사용하는 것이 좋습니다. 특히 사용중인 경우 쿠키 백엔드.

특히 쿠키 백엔드를 사용중이라면 자신의 직렬화 작성에 설명 된주의 사항이 있더라도 JSON 직렬화를 사용하는 것이 좋습니다.
⁶⁶⁾

예를 들어, `pickle`을 사용하여 세션 데이터를 직렬화하는 경우 공격 시나리오가 있습니다. 서명 된 쿠키 세션 백엔드 및 `SECRET_KEY`)를 사용하는 경우, 공격자에 의해 알려지며 (Django의 고유 한 취약점으로 인해 누출 될 수 있음), 공격자는 문자열을 자신의 세션에 추가합니다. 이 세션은 unpickle 될 때 서버에서 임의의 코드를 실행합니다. 그렇게 하기 위한 기술은 간단하고 인터넷에서 쉽게 이용할 수 있습니다. 쿠키 세션 저장소가 변조를 방지하기 위해 쿠키에 저장된 데이터에 서명하지만 SECRET_KEY 누출이 즉시 원격 코드 실행 취약점으로 확대됩니다
⁶⁷⁾

⁶⁸⁾

`django.core.signing`의 JSON 시리얼 라이저에 대한 래퍼. 기본 데이터 형식 만 serialize 할 수 있습니다.
⁶⁹⁾

또한 JSON은 문자열 키만 지원하므로 request.session의 문자열이 아닌 키를 사용하면 예상대로 작동하지 않습니다.
⁷⁰⁾

snippet.python

# initial assignment
request.session[0] = 'bar'
 
# subsequent requests following serialization & deserialization
# of session data 
request.session[0]     # KeyError
request.session['0']
'bar'

마찬가지로 JSON에서 인코딩 할 수 없는 데이터 (예: `UnicodeDecodeError`가 발생하는 '\ xd9'\와 같은 UTF8이 아닌 바이트)는 저장할 수 없습니다.
⁷¹⁾

JSON 직렬화의 제한 사항에 대한 자세한 내용은 자체 시리얼 작성 섹션을 참조하십시오.
⁷²⁾

임의의 파이썬 개체를 지원하지만 위에서 설명한대로 `SECRET_KEY`가 있으면 원격 코드 실행 취약점이 발생할 수 있습니다. )가 공격자에게 알려지게 됩니다.
⁷³⁾

`PickleSerializer`와 달리 `JSONSerializer` 임의의 파이썬 데이터 유형을 처리 할 수 ​​없습니다. 종종 그렇듯이 편의성과 보안 성 사이에는 트레이드 오프가 있습니다.
⁷⁴⁾

datetime과 Decimal을 포함한 더 진보 된 데이터 타입을 JSON 지원 세션에 저장하고 싶다면, 커스텀 시리얼 라이저를 작성하거나 (request.session에 저장하기 전에 이러한 값을 JSON 직렬화 가능한 객체로 변환해야합니다). 이러한 값을 직렬화하는 것은 매우 간단합니다 (`DjangoJSONEncoder` 도움이 될 수 있습니다. 디코더는 안정적으로 당신이 넣는 것과 똑같은 것을 되 찾을 수 있습니다.
⁷⁵⁾

예를 들어 datetime을 반환 할 위험이 있습니다. 실제로는 datetime과 같은 형식으로 된 문자열입니다.
⁷⁶⁾

serializer 클래스는 세션 데이터의 사전을 직렬화 및 비 직렬화하는 두 가지 메소드, dumps(self, obj) 및 loads(self, data)를 구현해야 합니다.
⁷⁷⁾

• request.session에서 사전 파이썬 문자열을 사전 키로 사용하십시오. 이는 어렵고 빠른 규칙보다 관례입니다.⁷⁸⁾
• 밑줄로 시작하는 세션 사전 키는 장고의 내부 용으로 예약되어 있습니다. ⁷⁹⁾
• request.session을 새로운 객체로 오버라이드하지 말고 그 속성에 접근하거나 설정하지 마라. 파이썬 사전처럼 사용하십시오.⁸⁰⁾

이 간단한보기는 사용자가 주석을 게시 한 후 has_commented 변수를 True로 설정합니다. 사용자가 한 번 이상 주석을 게시 할 수 없습니다.
⁸¹⁾

snippet.python

def post_comment(request, new_comment):
    if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")
    c = comments.Comment(comment=new_comment)
    c.save()
    request.session['has_commented'] = True
    return HttpResponse('Thanks for your comment!')

이 간단한보기는 사이트의 “회원”에 로그인합니다. ⁸²⁾

snippet.python

def login(request):
    m = Member.objects.get(username=request.POST['username'])
    if m.password == request.POST['password']:
        request.session['member_id'] = m.id
        return HttpResponse("You're logged in.")
    else:
        return HttpResponse("Your username and password didn't match.")

… 그리고 위의 login()에 따라 이 멤버를 로그 아웃합니다: ⁸³⁾

snippet.python

def logout(request):
    try:
        del request.session['member_id']
    except KeyError:
        pass
    return HttpResponse("You're logged out.")

표준 `django.contrib.auth.logout ()` 함수는 실제로 약간의 기능 을합니다. 부주의한 데이터 유출을 막기 위해 request()의 `flush()` 메소드를 호출합니다. 세션. 우리는 완전한 logout() 구현이 아닌 세션 객체를 다루는 방법을 보여주기 위해이 예제를 사용하고 있습니다.
⁸⁴⁾

⁸⁵⁾

편의상 Django는 사용자의 브라우저가 쿠키를 허용하는지 테스트하는 쉬운 방법을 제공합니다.
⁸⁶⁾

request.session의 `set_test_cookie()` 메소드를 호출하기만 하면됩니다. [test_cookie_worked ()] (https://docs.djangoproject.com/en/1.11/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase.test_cookie_worked)를 호출하십시오. - 동일한 뷰 호출이 아닌 후속 뷰에서 호출합니다.
⁸⁷⁾

쿠키가 작동하는 방식 때문에 set_test_cookie () 와 test_cookie_worked () 사이의 어색한 분리가 필요합니다. 쿠키를 설정하면 브라우저의 다음 요청이있을 때까지 브라우저가 쿠키를 허용했는지 여부를 실제로 알 수 없습니다.
⁸⁸⁾

청소하기 위해 `delete_test_cookie()`를 사용하는 것이 좋습니다. 너 자신 후에. 테스트 쿠키가 작동하는지 확인한 후에이 작업을 수행하십시오.
⁸⁹⁾

다음은 일반적인 사용 예입니다.
⁹⁰⁾

snippet.python

from django.http import HttpResponse
from django.shortcuts import render
 
def login(request):
    if request.method == 'POST':
        if request.session.test_cookie_worked():
            request.session.delete_test_cookie()
            return HttpResponse("You're logged in.")
        else:
            return HttpResponse("Please enable cookies and try again.")
    request.session.set_test_cookie()
    return render(request,'foo/login_form.html')

⁹¹⁾

Note

이 섹션의 예제는 django.contrib.sessions.backends.db 백엔드에서 직접 SessionStore 객체를 가져옵니다. 자신의 코드에서 `SESSION_ENGINE`에 의해 지정된 세션 엔진으로부터 SessionStore를 가져 오는 것을 고려해야합니다. 아래:
⁹²⁾

snippet.python

from importlib import import_module
from django.conf import settings
SessionStore = import_module(settings.SESSION_ENGINE).SessionStore

뷰 외부에서 세션 데이터를 조작하는 데 사용할 수있는 API는 다음과 같습니다.
⁹³⁾

snippet.python

from django.contrib.sessions.backends.db import SessionStore
s = SessionStore()
# stored as seconds since epoch since datetimes are not serializable in JSON.
s['last_login'] = 1376587691
s.create()
s.session_key
'2b1189a188b44ad18c35e113ac6ceead'
s = SessionStore(session_key='2b1189a188b44ad18c35e113ac6ceead')
s['last_login']
1376587691

SessionStore.create()는 새로운 세션 (즉, 세션 저장소에서 로드되지 않고 session_key = None)을 생성하도록 설계되었습니다 .save()는 기존 세션을 저장하도록 설계되었습니다 (즉, 세션 저장소). 새 세션에서 save()를 호출해도 작동하지만 기존 세션과 충돌하는 session_key를 생성 할 가능성은 거의 없습니다. create()는 save()를 호출하고 사용되지 않는 session_key가 생성 될 때까지 반복합니다.
⁹⁴⁾

django.contrib.sessions.backends.db 백엔드를 사용한다면, 각 세션은 정상적인 Django 모델 일뿐입니다. Session 모델은 django/contrib/sessions/models.py에 정의되어 있습니다. 정상적인 모델이기 때문에 일반적인 Django 데이터베이스 API를 사용하여 세션에 액세스 할 수 있습니다.
⁹⁵⁾

snippet.python

from django.contrib.sessions.models import Session
s = Session.objects.get(pk='2b1189a188b44ad18c35e113ac6ceead')
s.expire_date
datetime.datetime(2005, 8, 20, 13, 35, 12)

`get_decoded()`를 다음과 같이 호출해야 합니다. 세션 사전을 얻으십시오. 이는 사전이 인코딩 된 형식으로 저장되기 때문에 필요합니다.
⁹⁶⁾

snippet.python

s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
s.get_decoded()
{'user_id': 42}

⁹⁷⁾

기본적으로 Django는 세션이 수정되었을 때, 즉 사전 값이 할당되거나 삭제 된 경우에만 세션 데이터베이스에 저장합니다.
⁹⁸⁾

snippet.python

# Session is modified.
request.session['foo'] = 'bar'
 
# Session is modified.
del request.session['foo']
 
# Session is modified.
request.session['foo'] = {}
 
# Gotcha: Session is NOT modified, because this alters
# request.session['foo'] instead of request.session.
request.session['foo']['bar'] = 'baz'

위 예제의 마지막 경우에 세션 객체에 modified 속성을 설정하여 세션 객체가 명시 적으로 변경되었음을 세션 객체에 알릴 수 있습니다 :
⁹⁹⁾

snippet.python

request.session.modified = True

이 기본 동작을 변경하려면 `SESSION_SAVE_EVERY_REQUEST` 설정을 'True'으로 설정하십시오. True로 설정되면 Django는 매 요청마다 데이터베이스에 세션을 저장합니다.
¹⁰⁰⁾

세션 쿠키는 세션이 생성되거나 수정 된 경우에만 전송됩니다. `SESSION_SAVE_EVERY_REQUEST`가 True이면 모든 요청에 ​​세션 쿠키가 전송됩니다.
¹⁰¹⁾

비슷하게, 세션 쿠키의 expire 부분은 세션 쿠키가 전송 될 때마다 업데이트됩니다.
¹⁰²⁾

응답의 상태 코드가 500이면 세션이 저장되지 않습니다.
¹⁰³⁾

You can control whether the session framework uses browser-length sessions vs. persistent sessions with the`SESSION_EXPIRE_AT_BROWSER_CLOSE`setting.

By default,`SESSION_EXPIRE_AT_BROWSER_CLOSE`is set toFalse, which means session cookies will be stored in users’ browsers for as long as`SESSION_COOKIE_AGE`. Use this if you don’t want people to have to log in every time they open a browser.

If`SESSION_EXPIRE_AT_BROWSER_CLOSE`is set toTrue, Django will use browser-length cookies – cookies that expire as soon as the user closes their browser. Use this if you want people to have to log in every time they open a browser.

This setting is a global default and can be overwritten at a per-session level by explicitly calling the`set_expiry()`method ofrequest.sessionas described above inusing sessions in views.

Note

Some browsers (Chrome, for example) provide settings that allow users to continue browsing sessions after closing and re-opening the browser. In some cases, this can interfere with the`SESSION_EXPIRE_AT_BROWSER_CLOSE`setting and prevent sessions from expiring on browser close. Please be aware of this while testing Django applications which have the`SESSION_EXPIRE_AT_BROWSER_CLOSE`setting enabled.

As users create new sessions on your website, session data can accumulate in your session store. If you’re using the database backend, thedjango_sessiondatabase table will grow. If you’re using the file backend, your temporary directory will contain an increasing number of files.

To understand this problem, consider what happens with the database backend. When a user logs in, Django adds a row to thedjango_sessiondatabase table. Django updates this row each time the session data changes. If the user logs out manually, Django deletes the row. But if the user doesnotlog out, the row never gets deleted. A similar process happens with the file backend.

Django doesnotprovide automatic purging of expired sessions. Therefore, it’s your job to purge expired sessions on a regular basis. Django provides a clean-up management command for this purpose:`clearsessions`. It’s recommended to call this command on a regular basis, for example as a daily cron job.

Note that the cache backend isn’t vulnerable to this problem, because caches automatically delete stale data. Neither is the cookie backend, because the session data is stored by the users’ browsers.

A fewDjango settingsgive you control over session behavior:

• `SESSION_CACHE_ALIAS`
• `SESSION_COOKIE_AGE`
• `SESSION_COOKIE_DOMAIN`
• `SESSION_COOKIE_HTTPONLY`
• `SESSION_COOKIE_NAME`
• `SESSION_COOKIE_PATH`
• `SESSION_COOKIE_SECURE`
• `SESSION_ENGINE`
• `SESSION_EXPIRE_AT_BROWSER_CLOSE`
• `SESSION_FILE_PATH`
• `SESSION_SAVE_EVERY_REQUEST`
• `SESSION_SERIALIZER`

Subdomains within a site are able to set cookies on the client for the whole domain. This makes session fixation possible if cookies are permitted from subdomains not controlled by trusted users.

For example, an attacker could log intogood.example.comand get a valid session for their account. If the attacker has control overbad.example.com, they can use it to send their session key to you since a subdomain is permitted to set cookies on*.example.com. When you visitgood.example.com, you’ll be logged in as the attacker and might inadvertently enter your sensitive personal data (e.g. credit card info) into the attackers account.

Another possible attack would be ifgood.example.comsets its`SESSION_COOKIE_DOMAIN` to".example.com"which would cause session cookies from that site to be sent tobad.example.com.

• The session dictionary accepts any
  `json`
  serializable value when using
  `JSONSerializer`
  or any picklable Python object when using
  `PickleSerializer`
  . See the
  `pickle`
  module for more information.
• Session data is stored in a database table named
  django_session
  .
• Django only sends a cookie if it needs to. If you don’t set any session data, it won’t send a session cookie.

When working with sessions internally, Django uses a session store object from the corresponding session engine. By convention, the session store object class is namedSessionStoreand is located in the module designated by`SESSION_ENGINE`.

AllSessionStoreclasses available in Django inherit from`SessionBase`and implement data manipulation methods, namely:

• exists()
• create()
• save()
• delete()
• load()
• `clear_expired()`

In order to build a custom session engine or to customize an existing one, you may create a new class inheriting from`SessionBase`or any other existingSessionStoreclass.

Extending most of the session engines is quite straightforward, but doing so with database-backed session engines generally requires some extra effort (see the next section for details).

Creating a custom database-backed session engine built upon those included in Django (namelydbandcached_db) may be done by inheriting`AbstractBaseSession`and eitherSessionStoreclass.

AbstractBaseSessionandBaseSessionManagerare importable fromdjango.contrib.sessions.base_sessionso that they can be imported without includingdjango.contrib.sessionsin`INSTALLED_APPS`.

class

base_session.

AbstractBaseSession

¶

The abstract base session model.

session_key

¶

Primary key. The field itself may contain up to 40 characters. The current implementation generates a 32-character string (a random sequence of digits and lowercase ASCII letters).

session_data

¶

A string containing an encoded and serialized session dictionary.

expire_date

¶

A datetime designating when the session expires.

Expired sessions are not available to a user, however, they may still be stored in the database until the`clearsessions`management command is run.

classmethod

get_session_store_class

()

¶

Returns a session store class to be used with this session model.

get_decoded

()

¶

Returns decoded session data.

Decoding is performed by the session store class.

You can also customize the model manager by subclassing`BaseSessionManager`:

class

base_session.

BaseSessionManager

¶

encode

(

session_dict

)

¶

Returns the given session dictionary serialized and encoded as a string.

Encoding is performed by the session store class tied to a model class.

save

(

session_key

,

session_dict

,

expire_date

)

¶

Saves session data for a provided session key, or deletes the session in case the data is empty.

Customization ofSessionStoreclasses is achieved by overriding methods and properties described below:

class

backends.db.

SessionStore

¶

Implements database-backed session store.

classmethod

get_model_class

()

¶

Override this method to return a custom session model if you need one.

create_model_instance

(

data

)

¶

Returns a new instance of the session model object, which represents the current session state.

Overriding this method provides the ability to modify session model data before it’s saved to database.

class

backends.cached_db.

SessionStore

¶

Implements cached database-backed session store.

cache_key_prefix

¶

A prefix added to a session key to build a cache key string.

The example below shows a custom database-backed session engine that includes an additional database column to store an account ID (thus providing an option to query the database for all active sessions for an account):

from
django.contrib.sessions.backends.db
import
SessionStore
as
DBStore
from
django.contrib.sessions.base_session
import
AbstractBaseSession
from
django.db
import
models
class
CustomSession
(
AbstractBaseSession
):
account_id
=
models
.
IntegerField
(
null
=
True
,
db_index
=
True
)
@classmethod
def
get_session_store_class
(
cls
):
return
SessionStore
class
SessionStore
(
DBStore
):
@classmethod
def
get_model_class
(
cls
):
return
CustomSession
def
create_model_instance
(
self
,
data
):
obj
=
super
(
SessionStore
,
self
)
.
create_model_instance
(
data
)
try
:
account_id
=
int
(
data
.
get
(
'_auth_user_id'
))
except
(
ValueError
,
TypeError
):
account_id
=
None
obj
.
account_id
=
account_id
return
obj

If you are migrating from the Django’s built-incached_dbsession store to a custom one based oncached_db, you should override the cache key prefix in order to prevent a namespace clash:

class
SessionStore
(
CachedDBStore
):
cache_key_prefix
=
'mysessions.custom_cached_db_backend'
# ...

The Django sessions framework is entirely, and solely, cookie-based. It does not fall back to putting session IDs in URLs as a last resort, as PHP does. This is an intentional design decision. Not only does that behavior make URLs ugly, it makes your site vulnerable to session-ID theft via the “Referer” header.