Активируем сессии¶

Сессии реализованы через промежуточный слой.

Чтобы активировать сессии, выполните следующие действия:

• Убедитесь, что MIDDLEWARE_CLASSES содержит 'django.contrib.sessions.middleware.SessionMiddleware'. settings.py по умолчанию, созданный django-admin startproject, уже содержит SessionMiddleware.

Если вы не собираетесь использовать сессии, вы можете удалить SessionMiddleware из MIDDLEWARE_CLASSES и 'django.contrib.sessions' из INSTALLED_APPS. Это немного повысит производительность.

Настройка сессий¶

По умолчанию, Django хранит сессии в базе данных (используя модель django.contrib.sessions.models.Session). В некоторых случаях лучше хранить данные сессии в других хранилищах, поэтому Django позволяет использовать файловую систему или кэш.

Использование сессии в представлениях¶

Когда SessionMiddleware активный, каждый объект HttpRequest – первый аргумент представления в Django – будет содержать атрибут session, который является объектом с интерфейсом словаря.

Вы можете читать и менять request.session в любом месте вашего представления множество раз.

class backends.base.SessionBase¶

Это базовый класс для всех объектов сессии. Он предоставляет набор стандартных методов словаря:

__getitem__(key)¶

Например: fav_color = request.session['fav_color']

__setitem__(key, value)¶

Например: request.session['fav_color'] = 'blue'

__delitem__(key)¶

Например: del request.session['fav_color']. Вызовет KeyError, если key ещё не в сессии.

__contains__(key)¶

Например: 'fav_color' in request.session

get(key, default=None)¶

aget(key, default=None)¶

Асинхронная версия: aget()

Например: fav_color = request.session.get('fav_color', 'red')

Changed in Django 5.1:

Добавлена ​​функция aget().

aset(key, value)¶

New in Django 5.1.

Пример: await request.session.aset('fav_color', 'red')

update(dict)¶

aupdate(dict)¶

Асинхронная версия: aupdate()

Пример: request.session.update({'fav_color': 'red'})

Changed in Django 5.1:

Добавлена ​​функция aupdate().

pop(key, default=__not_given)¶

apop(key, default=__not_given)¶

Асинхронная версия: apop()

Например: fav_color = request.session.pop('fav_color')

Changed in Django 5.1:

Добавлена ​​функция apop().

keys()¶

akeys()¶

Асинхронная версия: keys()

Changed in Django 5.1:

Добавлена ​​функция keys().

values()¶

avalues()¶

Асинхронная версия: avalues()

Changed in Django 5.1:

Добавлена ​​функция avalues().

has_key(key)¶

ahas_key(key)¶

Асинхронная версия: ahas_key()

Changed in Django 5.1:

Добавлена ​​функция ahas_key().

items()¶

aitems()¶

Асинхронная версия: aitems()

Changed in Django 5.1:

Добавлена ​​функция aitems().

setdefault()¶

asetdefault()¶

Асинхронная версия: asetdefault()

Changed in Django 5.1:

Добавлена ​​функция asetdefault().

clear()¶

Также содержит следующие методы:

flush()¶

aflush()¶

Асинхронная версия: aflush()

Удаляет данные текущей сессии и сессионную куку. Можно использовать, если необходимо убедиться, что старые данные не доступны с браузера пользователя (например, функция django.contrib.auth.logout() вызывает этот метод).

Changed in Django 5.1:

Добавлена ​​функция aflush().

set_test_cookie()¶

aset_test_cookie()¶

Асинхронная версия: aset_test_cookie()

Устанавливает тестовую куку, чтобы проверить, что браузер пользователя поддерживает куки. Из-за особенностей работы кук вы не сможете проверить тестовую куку, пока пользователь не запросит следующую страницу. Подробности смотрите ниже (Setting test cookies).

Changed in Django 5.1:

Добавлена ​​функция aset_test_cookie().

test_cookie_worked()¶

atest_cookie_worked()¶

Асинхронная версия: atest_cookie_worked()

Возвращает либо True, либо False, в зависимости от того, принял ли браузер пользователя тестовый файл cookie. Из-за особенностей работы файлов cookie вам придется вызывать set_test_cookie() или aset_test_cookie() при предыдущем запросе отдельной страницы. Дополнительную информацию см. в разделе «Настройка тестовых файлов cookie» ниже.

Changed in Django 5.1:

Добавлена ​​функция atest_cookie_worked().

delete_test_cookie()¶

adelete_test_cookie()¶

Асинхронная версия: adelete_test_cookie()

Удаляет тестовую куку. Используйте, чтобы убрать за собой.

Changed in Django 5.1:

Добавлена ​​функция adelete_test_cookie().

get_session_cookie_age()¶

Возвращает значение параметра SESSION_COOKIE_AGE. Это можно переопределить в пользовательском бэкэнде сеанса.

set_expiry(value)¶

aset_expiry(value)¶

Асинхронная версия: aset_expiry()

Указывает время жизни сессии. Вы можете передать различные значения:

• Если value целое число, сессия истечет после указанного количества секунд неактивности пользователя. Например, request.session.set_expiry(300) установит время жизни равное 5 минутам.

• Если value является объектом datetime или timedelta, срок действия сеанса истечет в эту конкретную дату/время.

• Если value равно 0, срок действия файла cookie сеанса пользователя истечет при закрытии веб-браузера пользователя.

• Если value равно None, сессия будет использовать глобальное поведение.

Чтение сессии не обновляет время жизни сессии. Время жизни просчитывается с момента последнего изменения.

Changed in Django 5.1:

Добавлена ​​функция aset_expiry().

get_expiry_age()¶

aget_expiry_age()¶

Асинхронная версия: aget_expiry_age()

Возвращает время в секундах до окончания действия сессии. Для сессий без времени окончания (или для тех, что действуют пока работает браузер), значение будет равно SESSION_COOKIE_AGE.

Функция понимает два необязательных именованных аргумента:

• modification: время последнего изменения сессии в виде объекта datetime. По умолчанию соответствует текущему времени.

• expiry: информация об истечении срока действия сеанса в виде объекта datetime, int (в секундах) или None. По умолчанию используется значение, сохраненное в сеансе с помощью set_expiry()/aset_expiry(), если оно есть, или None.

Примечание

Этот метод используется серверными модулями сеанса для определения срока истечения сеанса в секундах при его сохранении. На самом деле он не предназначен для использования вне этого контекста.

В частности, хотя возможно определить оставшееся время жизни сеанса только тогда, когда у вас есть правильное значение modification и expiry установлен как объект datetime, где у вас есть значение modification, проще вычислить срок действия вручную:

expires_at = modification + timedelta(seconds=settings.SESSION_COOKIE_AGE)

Changed in Django 5.1:

Добавлена ​​функция aget_expiry_age().

get_expiry_date()¶

aget_expiry_date()¶

Асинхронная версия: aget_expiry_date()

Возвращает дату окончания действия сессии. Для сессий, у которых дата завершения не указана (или которые завершаются при закрытии браузера), значением будет дата, отстоящая на SESSION_COOKIE_AGE секунд от текущего момента.

Эта функция принимает те же ключевые аргументы, что и get_expiry_age(), и применяются аналогичные примечания по использованию.

Changed in Django 5.1:

Добавлена ​​функция aget_expiry_date().

get_expire_at_browser_close()¶

aget_expire_at_browser_close()¶

Асинхронная версия: aget_expire_at_browser_close()

Возвращает либо True, либо False, в зависимости от того, истечет ли срок действия файла cookie сеанса пользователя при закрытии веб-браузера пользователя.

Changed in Django 5.1:

Добавлена ​​функция aget_expire_at_browser_close().

clear_expired()¶

aclear_expired()¶

Асинхронная версия: clear_expired()

Удаляет просроченные сессии из хранилища сессий. Этот метод класса используется clearsessions.

Changed in Django 5.1:

Добавлена ​​функция clear_expired().

cycle_key()¶

acycle_key()¶

Асинхронная версия: acycle_key()

Создает новый ключ сессии при сохранении текущих данных в ней. Функция django.contrib.auth.login() вызывает этот метод, чтобы противодействовать фиксации сессии.

Changed in Django 5.1:

Добавлена ​​функция acycle_key().

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.check_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.")

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

Установка проверочных кук¶

Для удобства Django представляет простой способ проверить принимает ли браузер пользователя куки или нет. Просто вызовите метод set_test_cookie() объекта request.session в предоставлении и затем вызовите метод test_cookie_worked() в следующем вызове представления, это важный момент.

Такое неудобное разделение set_test_cookie() и test_cookie_worked() между вызовами предоставления необходимо из-за особенностей работы механизма кук. Когда вы устанавливаете куку, вы не можете гарантировать, что браузер действительно принял куке до тех пор, пока браузер не выполнит следующий запрос.

Хорошим тоном будет использование метода delete_test_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")

Использование сессий вне представлений¶

>>> 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() в новом сеансе также может сработать, но имеет небольшую вероятность создания session_key, который конфликтует с существующим. 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 на то, что необходимо сохранять сессию в базу данных при каждом запросе.

Следует отметить, что сессионная кука отправляется только при создании и модификации сессии. Если параметр конфигурации SESSION_SAVE_EVERY_REQUEST установлен в True, сессионная кука будет отправляться на каждый запрос.

Аналогично, значение атрибутп expires сессионной куки обновляется при каждой её отправке.

Сессия не сохраняется, если отклик имеет статус 500.

Разница между временными и постоянными куками¶

Вы можете указать какой должна быть длительность сессии, пока браузер не завершается или до некоторой даты, с помощью параметра конфигурации SESSION_EXPIRE_AT_BROWSER_CLOSE.

По умолчанию параметр конфигурации SESSION_EXPIRE_AT_BROWSER_CLOSE установлен в False, это означает, что сессионные куки будут храниться в браузере пользователя до тех пор, пока не истечёт время, указанное в параметре конфигурации SESSION_COOKIE_AGE. Используйте это если не желаете, чтобы пользователи авторизовались на сайте при каждом открытии браузера.

Если параметр конфигурации SESSION_EXPIRE_AT_BROWSER_CLOSE установлен в True, то Django будет использовать временные куки, такие куки работают до момента закрытия браузера. Используйте это если желаете, чтобы пользователи авторизовались на сайте при каждом открытии браузера.

Данный параметр конфигурации является глобальным, но может быть переопределён на уровне сессии с помощью явного вызова метода set_expiry() объекта request.session как было описано выше в using sessions in views.

Очистка хранилища сессии¶

По мере создания пользователями новых сессий на вашем сайте в хранилище сессий накапливаются данные этих сессий. При использовании базы данных в качестве хранилища, таблица django_session постепенно наполняется. При использовании файлов в качестве хранилища, временный каталог будет содержать всё больше и больше файлов.

Для понимания проблемы давайте рассмотрим, что произойдёт с хранилищем на основе базы данных. При авторизации пользователя Django добавляет запись в таблицу django_session. Django обновляет эту запись при каждом изменении данных сессии. Если пользователь завершает сеанс явно, то Django удаляет эту запись. В противном случае эта запись не удаляется. Похожее происходит и в случае файлового хранилища.

Django не обеспечивает автоматическую очистку просроченных сессий. Следовательно, эта задача ложится на вас на регулярной основе. Django представляет для этой цели команду очистки: clearsessions. Рекомендуется выполнять эту команду на регулярной основе, например, через cron ежедневно.

Следует отметить, что хранилище на основе кэша не подтверждено этой проблеме так как кэш автоматически удаляет устаревшие данные. Так же нет проблемы и с хранилищем на основе кук, потому что они хранятся в браузерах у пользователей.

Параметры конфигурации¶

Несколько параметров конфигурации Django представляют вам управление поведением сессии:

• SESSION_CACHE_ALIAS

• SESSION_COOKIE_AGE

• SESSION_COOKIE_DOMAIN

• SESSION_COOKIE_HTTPONLY

• SESSION_COOKIE_NAME

• SESSION_COOKIE_PATH

• SESSION_COOKIE_NAME

• SESSION_COOKIE_SECURE

• SESSION_ENGINE

• SESSION_EXPIRE_AT_BROWSER_CLOSE

• SESSION_FILE_PATH

• SESSION_SAVE_EVERY_REQUEST

• SESSION_ENGINE

Безопасность сессии¶

Поддомены внутри сайта имеют возможность устанавливать куки на клиенте для всего домена. Это приводит к возможности фиксации сессии, если куки принимаются от поддоменов, которые не находятся под управлением доверенных пользователей.

Например, атакующий может авторизоваться на good.example.com и получить достоверную сессию для своего аккаунта. Если у атакующего есть контроль над bad.example.com, он может использовать его для отправки своего ключа сессии вам, так как поддомену разрешено устанавливать куки для *.example.com. Когда вы посетите good.example.com, вы будете авторизован как атакующий и можете непреднамеренно внести важные персональные данные (например, номер кредитной карты) в аккаунт атакующего.

Другой возможной атакой может быть ситуация, если сайт good.example.com имеет в параметре конфигурации SESSION_COOKIE_DOMAIN значение ".example.com", что может привести отправке сессионной куки на сайт bad.example.com.

Технические детали¶

• Словарь сеанса принимает любое сериализуемое значение json при использовании JSONSerializer.

• Данные сессии сохраняются в базе данных в таблице django_session .

• Django отправляем куки только когда это требуется. Если вы не сохранили никаких данных в сессию, то сессионная кука не будет отправляться.

Использование базы данных для хранения сессии¶

Создание собственного механизма сеансов с поддержкой базы данных, построенного на основе тех, что включены в Django (а именно db и cached_db), можно выполнить путем наследования AbstractBaseSession и любого из классов``SessionStore``.

AbstractBaseSession и BaseSessionManager можно импортировать из django.contrib.sessions.base_session, поэтому их можно импортировать без включения django.contrib.sessions в INSTALLED_APPS.

class base_session.AbstractBaseSession¶

Абстрактная модель базового сеанса.

session_key¶

Первичный ключ. Само поле может содержать до 40 символов. Текущая реализация генерирует 32-символьную строку (случайную последовательность цифр и строчных букв ASCII).

session_data¶

Строка, содержащая закодированный и сериализованный словарь сеанса.

expire_date¶

Дата и время, обозначающие дату окончания сеанса.

Сеансы с истекшим сроком действия недоступны пользователю, однако они все равно могут храниться в базе данных до тех пор, пока не будет запущена команда управления clearsessions.

classmethod get_session_store_class()¶

Возвращает класс хранилища сеансов, который будет использоваться с этой моделью сеанса.

get_decoded()¶

Возвращает декодированные данные сеанса.

Декодирование выполняется классом хранилища сеансов.

Вы также можете настроить менеджер моделей, создав подкласс BaseSessionManager:

class base_session.BaseSessionManager¶

encode(session_dict)¶

Возвращает заданный словарь сеанса, сериализованный и закодированный в виде строки.

Кодирование выполняется классом хранилища сеансов, привязанным к классу модели.

save(session_key, session_dict, expire_date)¶

Сохраняет данные сеанса для предоставленного сеансового ключа или удаляет сеанс, если данные пусты.

Настройка классов SessionStore достигается путем переопределения методов и свойств, описанных ниже:

class backends.db.SessionStore¶

Использование базы данных для хранения сессии

classmethod get_model_class()¶

Переопределите этот метод, чтобы вернуть пользовательскую модель сеанса, если она вам нужна.

create_model_instance(data)¶

Возвращает новый экземпляр объекта модели сеанса, который представляет текущее состояние сеанса.

Переопределение этого метода дает возможность изменять данные модели сеанса перед их сохранением в базе данных.

class 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

class SessionStore(CachedDBStore):
    cache_key_prefix = "mysessions.custom_cached_db_backend"

    # ...

Идентификаторы сессии в URL¶

Поддержка сессий в Django полностью, и исключительно, основана на кук. Django не помещает идентификатор сессии в URL в качестве крайнего варианта, как это делает PHP. Это - осознанное проектное решение. Мало того, что такое поведение делает URL уродливыми, оно делает ваш сайт уязвимым для воровства идентификатора сессии через заголовок «Referer».