Использование сессий ¶
Django полностью поддерживает анонимные сеансы. Инфраструктура сеанса позволяет хранить и извлекать произвольные данные по принципу «один сайт - один посетитель». Данные хранятся на стороне сервера; отправка и получение файлов cookie прозрачны. Файлы cookie содержат идентификатор сеанса, а не сами данные (если вы не используете механизм на основе файлов cookie ).
Активация сессий ¶
Сеансы реализуются через компонент промежуточного программного обеспечения .
Чтобы включить функцию сеансов, сделайте следующее:
- Убедитесь, что параметр
MIDDLEWARE
содержит'django.contrib.sessions.middleware.SessionMiddleware'
. Файлsettings.py
создается по умолчанию активным .django-admin startproject
SessionMiddleware
Если вы не хотите использовать сеансы, вы можете удалить строку SessionMiddleware
in MIDDLEWARE
и line 'django.contrib.sessions'
of INSTALLED_APPS
. Это сэкономит Django немного работы.
Настройка механизма сеанса ¶
По умолчанию Django хранит сеансы в базе данных (с шаблоном django.contrib.sessions.models.Session
). Хотя это может быть удобно, в некоторых конфигурациях быстрее хранить данные сеанса в другом месте; поэтому можно настроить Django для хранения данных сеанса в файловой системе или в кеше.
Использование сессий в базе данных ¶
Если вы хотите поместить содержимое сеансов в базу данных, вы должны добавить 'django.contrib.sessions'
настройку INSTALLED_APPS
.
После настройки установки запустите для установки единой таблицы базы данных, в которой хранятся данные сеанса.manage.py migrate
Использование кешированных сессий ¶
Для лучшей производительности рекомендуется использовать механизм сеанса на основе кеша.
Чтобы хранить данные сеанса с использованием системы кеширования Django, вам сначала нужно убедиться, что кеш настроен; см. документацию по кешу для получения более подробной информации.
Предупреждение
Данные сеанса следует кэшировать только при использовании механизма кэширования Memcached. Механизм кеширования локальной памяти не хранит данные достаточно долго, чтобы быть хорошим выбором, и быстрее использовать механизм сеанса на основе файлов или баз данных напрямую, чем передавать их через все с помощью механизмов кэширования на основе файлов или баз данных. Кроме того, механизм кэширования локальной памяти НЕ обрабатывает многопроцессорный режим должным образом и поэтому, вероятно, не является хорошим выбором в производственной среде.
Если несколько кешей определены в 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 хранит файлы сеанса. Убедитесь, что у веб-сервера есть разрешения на чтение и запись.
Использование сессий на основе файлов cookie ¶
Чтобы использовать сеансы на основе файлов cookie, установите для параметра SESSION_ENGINE
значение "django.contrib.sessions.backends.signed_cookies"
. Данные сеанса будут храниться с использованием инструментов Django для криптографической подписи и настройки SECRET_KEY
.
Заметка
Рекомендуется оставить параметр SESSION_COOKIE_HTTPONLY
равным значению, True
чтобы предотвратить доступ к сохраненным данным из JavaScript.
Предупреждение
** Если секретный ключ SECRET_KEY
больше не является секретным и вы используете ** PickleSerializer
, это может привести к произвольному удаленному выполнению кода.
Злоумышленник, владеющий секретным ключом, SECRET_KEY
может не только генерировать поддельные данные сеанса, которые будут допущены вашим сайтом, но также может удаленно выполнить произвольный код, поскольку данные сериализуются с помощью pickle
.
Если вы используете сеансы на основе файлов cookie, следует проявлять особую осторожность, чтобы всегда держать секретный ключ в абсолютном секрете для любой системы с удаленным доступом.
** данные сеанса подписаны, но не зашифрованы **
При использовании механизма на основе файлов cookie данные сеанса могут быть прочитаны клиентом.
MAC-код (код проверки подлинности сообщения) используется для защиты данных от модификации клиентом, поэтому данные сеанса недействительны, когда они были изменены. Такая же защита происходит, если клиент, который хранит cookie (например, браузер пользователя), не может сохранить весь файл cookie сеанса и усекает данные. Несмотря на то, что Django сжимает данные, все же возможно превышениеобычный лимит 4096 байт на файл cookie.
Нет гарантии свежести
Следует также отметить, что хотя MAC-код может гарантировать подлинность данных (что они действительно были созданы вашим сайтом), а также целостность этих данных (их полнота и правильность), он не может не гарантируем их свежесть, то есть вы получите последнюю версию, которую отправили заказчику. Это означает, что при определенном использовании данных сеанса механизм cookie может сделать вас уязвимыми для атак повторного воспроизведения., В отличие от других механизмов сеанса, которые хранят версию каждого сеанса на стороне сервера и переопределяют их, когда пользователь выходит из системы, сеансы на основе файлов cookie не отменяются, когда пользователь выходит из системы. Таким образом, если злоумышленник украдет cookie пользователя, он может использовать его для входа в систему под именем этого пользователя, даже если последний вышел из системы. Файлы cookie считаются устаревшими только тогда, когда их возраст превышает SESSION_COOKIE_AGE
.
Производительность
Наконец, размер файла cookie может влиять на скорость вашего сайта .
Использование сессий в представлениях ¶
Когда SessionMiddleware
он активен, каждый объект HttpRequest
, первый параметр любой функции представления Django, имеет атрибут, session
который является объектом типа словаря.
Вы можете читать и писать в него request.session
в любое время, когда вам будет удобно. Вы можете изменить его несколько раз.
-
класс
backends.base.
SessionBase
¶ Это базовый класс для всех объектов сеанса. Он имеет следующие стандартные словарные методы:
-
__getitem__
( ключ ) ¶ Пример:
-
__setitem__
( ключ , значение ) ¶ Пример:
request.session['fav_color'] = 'blue'
-
__delitem__
( ключ ) ¶ Пример: . Если указанный ключ еще не находится в объекте сеанса, создается исключение .
del request.session['fav_color']
KeyError
-
__contains__
( ключ ) ¶ Пример:
'fav_color' in request.session
-
get
( ключ , по умолчанию = Нет ) ¶ Пример:
fav_color = request.session.get('fav_color', 'red')
-
pop
( ключ , по умолчанию = __ not_given ) ¶ Пример:
fav_color = request.session.pop('fav_color', 'blue')
-
keys
() ¶
-
items
() ¶
-
setdefault
() ¶
-
clear
() ¶
Также есть следующие методы:
-
flush
() ¶ Удаляет данные для текущего сеанса и удаляет файл cookie сеанса. Это полезно для обеспечения того, чтобы данные предыдущего сеанса больше не могли воспроизводиться браузером пользователя (например, он это делает
django.contrib.auth.logout()
).
Создает тестовый файл cookie, чтобы определить, поддерживает ли браузер пользователя файлы cookie. Из-за того, как работают файлы cookie, вы не сможете определить это до следующего запроса пользователя. См. Раздел Создание тестовых файлов cookie ниже для получения дополнительной информации.
Возвращает
True
илиFalse
, в зависимости от того, принял ли браузер пользователя тестовый файл cookie или нет. Из-за того, как работают файлы cookie, вы должны были вызватьset_test_cookie()
предыдущий запрос страницы. См. Раздел Создание тестовых файлов cookie ниже для получения дополнительной информации.
Удалите тестовый файл cookie. Используется для уборки позади вас.
- Новое в Django 3.0.
Возвращает возраст файлов cookie сеанса в секундах. По умолчанию это
SESSION_COOKIE_AGE
.
-
set_expiry
( значение ) ¶ Определяет, как долго истекает сеанс. Можно передать несколько разных значений:
- Если
value
- целое число, сеанс завершится по истечении указанного количества секунд бездействия. Например, при вызовеrequest.session.set_expiry(300)
сеанс истечет через 5 минут. - Если
value
это объектdatetime
илиtimedelta
, сеанс истечет в указанную дату и время. Обратите внимание, что значенияdatetime
иtimedelta
сериализуемы, только если вы используете сериализациюPickleSerializer
. - Если
value
это0
, куки сессии пользователя истекает , когда пользователь закрывает свой веб - браузер. - Если
value
естьNone
, то сессия вновь опирается на глобальную политику истечения срока действия сеанса.
Чтение сеанса не считается занятием с точки зрения истечения срока действия. Срок действия сеанса исчисляется с момента последнего изменения сеанса.
- Если
-
get_expiry_age
() ¶ Возвращает количество секунд, оставшихся до истечения сеанса. Для сеансов без определенного срока действия (или сеансов, срок действия которых истекает при закрытии браузера) это значение будет равно
SESSION_COOKIE_AGE
.Эта функция принимает два необязательных именованных параметра:
modification
: последняя модификация сеанса как объектdatetime
. По умолчанию это текущее время.expiry
: информация об истечении срока действия сеанса, например объектdatetime
, значениеint
(в секундах) илиNone
. По умолчанию это значение равно значению, сохраненному в сеансеset_expiry()
, если применимо, в противном случаеNone
.
-
get_expiry_date
() ¶ Возвращает дату окончания сеанса. Для сеансов без определенного тайм-аута (или тех, которые истекают при закрытии браузера), это значение будет равно
SESSION_COOKIE_AGE
секундам с этого момента .Эта функция принимает те же параметры ключевого слова, что и
get_expiry_age()
.
-
get_expire_at_browser_close
() ¶ Возвращает
True
или вFalse
зависимости от того, истекает ли срок действия cookie сеанса пользователя при закрытии веб-браузера пользователя или нет.
-
clear_expired
() ¶ Удаляет просроченные сеансы из хранилища сеансов. Этот метод класса вызывается
clearsessions
.
-
cycle_key
() ¶ Создает новый ключ сеанса с сохранением данных текущего сеанса.
django.contrib.auth.login()
вызывает этот метод для борьбы с атаками фиксации сеанса.
-
Сериализация сессий ¶
По умолчанию Django сериализует данные сеанса в JSON. Вы можете использовать этот параметр SESSION_SERIALIZER
для настройки формата сериализации сеанса. Даже с учетом ограничений, описанных в разделе « Написание собственного сериализатора» , мы настоятельно рекомендуем придерживаться сериализации JSON, особенно если вы используете механизм cookie .
Например, вот сценарий атаки, если вы используете pickle
для сериализации данных сеанса. Если вы используете механизм сеанса на основе подписанных файлов cookie и ключ SECRET_KEY
известен злоумышленнику (в Django нет известной уязвимости, которая раскрыла бы эту информацию), этот злоумышленник может вставить строку в сеанс, это что может привести во время десериализации («распаковки») к выполнению произвольного кода на сервере. Техника для этого проста и легко доступна в Интернете. Даже если файлы cookie хранилища сеанса подписывают данные сеанса, чтобы предотвратить подделку, раскрытие ключа SECRET_KEY
немедленно создает уязвимость удаленного выполнения кода.
Встроенные сериализаторы ¶
-
класс
serializers.
JSONSerializer
¶ Адаптер сериализатора JSON из
django.core.signing
. Может сериализовать только простые типы данных.Кроме того, поскольку JSON поддерживает только текстовые ключи, имейте в виду, что нетекстовые ключи в
request.session
не будут работать должным образом:>>> # initial assignment >>> request.session[0] = 'bar' >>> # subsequent requests following serialization & deserialization >>> # of session data >>> request.session[0] # KeyError >>> request.session['0'] 'bar'
Точно так же данные, которые не могут быть закодированы в JSON, такие как байты, отличные от UTF-8, такие как
'\xd9'
(который производитUnicodeDecodeError
), не могут быть сохранены.Подробную информацию об ограничениях сериализации JSON см. В разделе « Написание собственного сериализатора».
-
класс
serializers.
PickleSerializer
¶ Принимает любой объект Python, но, как объяснено выше, может привести к уязвимости удаленного выполнения кода, если ключ
SECRET_KEY
будет раскрыт злоумышленнику.
Написание собственного сериализатора ¶
Обратите внимание, что, в отличие от PickleSerializer
, JSONSerializer
не может обрабатывать данные Python любого типа. Как это часто бывает, существует баланс между удобством и безопасностью. Если вы хотите хранить более специализированные типы данных, такие как сеансы datetime
или Decimal
в JSON, вам нужно будет написать свой собственный сериализатор (или преобразовать эти значения в сериализуемые объекты в JSON перед их сохранением request.session
). Хотя сериализация таких значений относительно проста ( DjangoJSONEncoder
дает подсказки), написать декодер, который может надежно восстановить начальное значение, сложнее. Например, вы можете создать объектdatetime
для того, что на самом деле было строкой, формат которой был похож на тот, который вы выбрали для представления объектов datetime
.
Класс сериализации должен реализовывать два метода и для сериализации и десериализации словаря данных сеанса соответственно.dumps(self, obj)
loads(self, data)
Рекомендации для объектов сеанса ¶
- Используйте обычные строки Python в качестве ключей словаря для
request.session
. Это больше условность, чем строгое правило. - Ключи словаря сеанса, начинающиеся с подчеркивания, зарезервированы для внутреннего использования Django.
- Не перегружайте
request.session
новый объект, не обращайтесь к его атрибутам и не изменяйте их. Используйте его как словарь Python.
Примеры ¶
Это очень простой вид устанавливает переменную , has_commented
чтобы True
после того, как пользователь отправляет комментарий. Он не допускает более одного комментария для каждого пользователя:
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!')
Это очень простое представление подключает "участника" сайта:
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()
выше пример :
def logout(request):
try:
del request.session['member_id']
except KeyError:
pass
return HttpResponse("You're logged out.")
Стандартная функция на django.contrib.auth.logout()
самом деле делает немного больше для предотвращения случайного раскрытия данных. Он вызывает метод flush()
из request.session
. Мы используем этот пример в качестве демонстрации того, как работают объекты сеанса, его не следует рассматривать как полную реализацию logout()
.
Создание тестовых файлов cookie ¶
Для удобства Django предоставляет способ проверить, принимает ли браузер пользователя файлы cookie. Вызов метода set_test_cookie()
из request.session
в представлении, а затем вызвать test_cookie_worked()
в одном из следующих представлений, но не в том же виде вызова.
Это странное разделение между set_test_cookie()
и test_cookie_worked()
необходимо из-за того, как работают файлы cookie. Когда вы устанавливаете файл cookie, на самом деле невозможно узнать, принял ли его браузер до получения следующего запроса браузера.
Рекомендуется использовать delete_test_cookie()
для уборки позади вас. Сделайте это, убедившись, что тестовый файл cookie работает.
Вот пример типичного использования:
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')
Использование сессий вне представлений ¶
Заметка
Примеры в этом разделе импортируют объект непосредственно SessionStore
из движка django.contrib.sessions.backends.db
. В вашем собственном коде лучше всего импортировать SessionStore
из механизма сеансов, обозначенного SESSION_ENGINE
, как показано ниже:
>>> from importlib import import_module
>>> from django.conf import settings
>>> SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
Доступен API для управления данными сеанса вне представлений:
>>> 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()
новый сеанс, но с небольшим риском создания сеансового ключа, который конфликтует с другим. create()
вызывает save()
и зацикливается, пока session_key
не будет произведен неиспользованный ключ .
Если вы используете движок django.contrib.sessions.backends.db
, каждый сеанс представляет собой обычную модель Django. Модель Session
определена в django/contrib/sessions/models.py
. Поскольку это обычная модель, вы можете получить доступ к сеансам, используя обычный API базы данных Django:
>>> 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()
чтобы получить словарь сеанса. Это необходимо, потому что словарь хранится в закодированном формате:
>>> s.session_data
'KGRwMQpTJ19hdXRoX3VzZXJfaWQnCnAyCkkxCnMuMTExY2ZjODI2Yj...'
>>> s.get_decoded()
{'user_id': 42}
Запись сеансов ¶
По умолчанию Django сохраняет сеанс в базе данных только тогда, когда сеанс был изменен, то есть по крайней мере одно из значений в его словаре было установлено или удалено:
# 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
:
request.session.modified = True
Чтобы изменить это поведение по умолчанию, установите для параметра SESSION_SAVE_EVERY_REQUEST
значение True
. В этом случае Django сохраняет сеанс в базе данных при каждом запросе.
Обратите внимание, что файл cookie сеанса отправляется только после создания или изменения сеанса. Если SESSION_SAVE_EVERY_REQUEST
применимо True
, cookie сеанса будет отправляться для каждого запроса.
Аналогичным образом, часть expires
файла cookie сеанса обновляется каждый раз при отправке файла cookie сеанса.
Сеанс не сохраняется, если код состояния ответа 500.
Истечение или сохранение сеанса ¶
Этот параметр SESSION_EXPIRE_AT_BROWSER_CLOSE
позволяет вам контролировать тип сеансов, используемых инфраструктурой сеансов: сеансы, срок действия которых истекает при закрытии браузера, или постоянные сеансы.
По умолчанию SESSION_EXPIRE_AT_BROWSER_CLOSE
установлено значение False
, что означает, что файлы cookie сеанса будут храниться в браузерах пользователей в течение периода SESSION_COOKIE_AGE
. Используется, когда вы не хотите, чтобы пользователям приходилось входить в систему каждый раз, когда они открывают свой браузер.
Если SESSION_EXPIRE_AT_BROWSER_CLOSE
установлено значение True
, Django использует файлы cookie, срок действия которых истекает при закрытии браузера. Используется, когда вы хотите, чтобы пользователи входили в систему каждый раз, когда они открывают свой браузер.
Этот параметр является глобальным по умолчанию и может быть переопределен на уровне отдельного сеанса путем явного вызова метода set_expiry()
из , request.session
как описано выше в Использование сессий в соображениях .
Заметка
Некоторые браузеры (например, Chrome) можно настроить так, чтобы не закрывать сеансы просмотра между закрытием и повторным открытием браузера. В некоторых случаях это может помешать настройке SESSION_EXPIRE_AT_BROWSER_CLOSE
и предотвратить истечение срока сеанса при закрытии браузера. Это важно знать при тестировании приложений Django с SESSION_EXPIRE_AT_BROWSER_CLOSE
активными настройками .
Очистка хранилища сеансов ¶
По мере того, как все больше пользователей создают новые сеансы на вашем веб-сайте, данные о сеансах накапливаются в вашем хранилище сеансов. Если вы используете движок в качестве базы данных, таблица базы данных django_session
увеличивается. Если вы используете файловый движок, количество файлов во временном каталоге будет постоянно увеличиваться.
Чтобы разобраться в этой проблеме, давайте посмотрим, что происходит с движком в базе данных. Когда пользователь входит в систему, Django добавляет запись в таблицу django_session
. Он обновляет эту запись при изменении данных сеанса. Если пользователь явно выходит из системы, Django очищает запись. Но если пользователь этого не сделает , запись никогда не будет стерта. Принцип тот же, что и для файлового движка.
Django не предоставляет автоматической системы удаления просроченных сессий. Таким образом, вы должны делать это через определенные промежутки времени. Django предоставляет команды управления очистки для этой цели: clearsessions
. Рекомендуется запускать эту команду регулярно, например, в ежедневном задании cron.
Обратите внимание, что механизм на основе кеша не подвержен этой проблеме, поскольку кеши автоматически удаляют устаревшие данные. То же самое и с движком на основе файлов cookie, поскольку данные сеанса хранятся в браузерах пользователей.
Настройки ¶
Некоторые настройки Django позволяют контролировать поведение сессий:
Безопасность сеанса ¶
Поддомены сайта могут устанавливать файлы cookie для клиента, действительные для всего домена. Это делает возможными атаки фиксации сеанса, если файлы cookie могут быть созданы субдоменами, которые не находятся под контролем доверенных лиц.
Например, злоумышленник может войти в систему good.example.com
и получить действительный сеанс для своей учетной записи. Если злоумышленник находится под контролем bad.example.com
, он может использовать его, чтобы отправить вам свой сеансовый ключ, поскольку поддомен имеет право устанавливать файлы cookie для *.example.com
. При посещении good.example.com
вы войдете в систему под учетной записью злоумышленника и сможете непреднамеренно ввести конфиденциальные личные данные (например, данные кредитной карты), сохраненные в учетной записи злоумышленника.
Другая возможная атака возникает в случае, если для good.example.com
параметра установлено SESSION_COOKIE_DOMAIN
значение "example.com"
, что может привести к отправке файлов cookie сеанса в bad.example.com
.
Технические детали ¶
- Словарь сеанса принимает любые данные, сериализуемые с
json
помощью,JSONSerializer
или любой объект Python, сериализуемый сpickle
помощьюPickleSerializer
. См.pickle
Дополнительную информацию в документации модуля . - Данные сеанса хранятся в именованной таблице базы данных
django_session
. - Django отправляет cookie только при необходимости. Если вы не укажете данные сеанса, cookie сеанса не будет отправлен.
Объект SessionStore
¶
Когда Django управляет сеансами изнутри, он использует объект хранилища сеансов из соответствующего механизма сеанса. По соглашению вызывается класс объекта хранения сеанса, который SessionStore
находится в модуле, обозначенном SESSION_ENGINE
.
Все классы, SessionStore
доступные в Django, наследуются от SessionBase
методов управления данными и реализуют их, в данном случае:
exists()
create()
save()
delete()
load()
clear_expired()
Чтобы создать собственный механизм сеанса или адаптировать существующий, вы можете создать новый класс, наследующий от SessionBase
любого другого SessionStore
существующего класса .
Можно расширить существующие механизмы сеанса, но для движков на базе баз данных это обычно требует немного больше работы (подробности читайте в следующем разделе).
Расширение движков сессий на основе баз данных ¶
Создание настраиваемого механизма сеанса, управляемого базой данных, на основе тех, что включены в Django (т.е. db
и cached_db
), может быть выполнено путем наследования AbstractBaseSession
от одного из классов. SessionStore
,
AbstractBaseSession
и BaseSessionManager
их можно импортировать из django.contrib.sessions.base_session
файлов, чтобы их можно было импортировать без включения django.contrib.sessions
в INSTALLED_APPS
.
-
класс
base_session.
AbstractBaseSession
¶ Базовая абстрактная модель сеанса.
-
session_key
¶ Первичный ключ. Само поле может содержать до 40 символов. Текущая реализация генерирует 32-символьную строку (случайную последовательность строчных цифр и букв ASCII).
-
session_data
¶ Строка, содержащая закодированный и сериализованный словарь сеанса.
-
expire_date
¶ Дата / время, указывающие дату окончания сеанса.
Сессии, срок действия которых истек, больше не доступны для пользователей; они могут оставаться в базе данных до запуска административной команды
clearsessions
.
-
classmethod
get_session_store_class
() ¶ Возвращает класс хранения сеанса для использования с этим шаблоном сеанса.
-
get_decoded
() ¶ Возвращает декодированные данные сеанса.
Декодирование выполняется классом хранения сеанса.
-
Вы также можете настроить диспетчер моделей, унаследовав от BaseSessionManager
:
-
класс
base_session.
BaseSessionManager
¶ -
encode
( session_dict ) ¶ Возвращает указанный словарь сеанса в виде закодированной и сериализованной строки.
Кодирование выполняется классом хранения сеанса, связанным с классом шаблона.
-
save
( session_key , session_dict , expire_date ) ¶ Сохраните данные сеанса, соответствующие указанному ключу сеанса, или удалите сеанс, если данные пусты.
-
Настройка классов SessionStore
выполняется путем перегрузки методов и свойств, описанных ниже:
-
класс
backends.db.
SessionStore
¶ Реализация хранилища сессий на базе базы данных.
-
classmethod
get_model_class
() ¶ Переопределите этот метод, чтобы при необходимости возвращать настраиваемый шаблон сеанса.
-
create_model_instance
( данные ) ¶ Возвращает новый экземпляр объекта шаблона сеанса, который представляет текущее состояние сеанса.
Переопределив этот метод, вы можете изменить данные шаблона сеанса до их сохранения в базе данных.
-
classmethod
-
класс
backends.cached_db.
SessionStore
¶ Реализация хранилища сеансов на основе базы данных и кеша.
-
cache_key_prefix
¶ Префикс, добавляемый к ключу сеанса для построения цепочки ключей кеша.
-
Пример ¶
В приведенном ниже примере показан настраиваемый механизм сеанса, управляемый базой данных, включая дополнительный столбец базы данных для хранения идентификатора учетной записи (и, таким образом, предоставляя возможность запрашивать базу данных для всех активные сеансы учетной записи):
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().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
Если вы переходите со cached_db
встроенного хранилища сеансов Django в пользовательское хранилище на основе cached_db
, рекомендуется переопределить префикс ключа кеша, чтобы избежать возможных конфликтов пространства имен:
class SessionStore(CachedDBStore):
cache_key_prefix = 'mysessions.custom_cached_db_backend'
# ...
Идентификаторы сеанса в URL ¶
Инфраструктура сеансов Django полностью основана на файлах cookie. Он не использует систему идентификаторов сеансов в URL-адресах, как это делает PHP. Это добровольное концептуальное решение. Этот метод искажает URL-адреса и делает ваш сайт уязвимым для кражи идентификатора сеанса через заголовок «Referer».