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

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

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

• Убедитесь, что 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)¶

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

pop(key, default=__not_given)¶

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

keys()¶

items()¶

setdefault()¶

clear()¶

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

flush()¶

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

set_test_cookie()¶

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

test_cookie_worked()¶

Returns either True or False, depending on whether the user’s browser accepted the test cookie. Due to the way cookies work, you’ll have to call set_test_cookie() on a previous, separate page request. See Setting test cookies below for more information.

delete_test_cookie()¶

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

get_session_cookie_age()¶

New in Django 3.0.

Returns the age of session cookies, in seconds. Defaults to SESSION_COOKIE_AGE.

set_expiry(value)¶

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

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

• If value is a datetime or timedelta object, the session will expire at that specific date/time. Note that datetime and timedelta values are only serializable if you are using the PickleSerializer.

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

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

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

get_expiry_age()¶

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

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

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

• expiry: expiry information for the session, as a datetime object, an int (in seconds), or None. Defaults to the value stored in the session by set_expiry(), if there is one, or None.

get_expiry_date()¶

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

This function accepts the same keyword arguments as get_expiry_age().

get_expire_at_browser_close()¶

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

clear_expired()¶

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

cycle_key()¶

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

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

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

An API is available to manipulate session data outside of a view:

>>> 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.

If you’re using the django.contrib.sessions.backends.db backend, each session is a normal Django model. The Session model is defined in django/contrib/sessions/models.py. Because it’s a normal model, you can access sessions using the normal Django database API:

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

Note that you’ll need to call get_decoded() to get the session dictionary. This is necessary because the dictionary is stored in an encoded format:

>>> 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.

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

• 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.

• Данные сессии сохраняются в базе данных в таблице 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».