Как использовать сессии

Django предоставляет полную поддержку анонимных сессий. Система сессий позволяет хранить и извлекать произвольные данные для каждого посетителя сайта. Данные хранятся на стороне сервера, а отправка и получение файлов cookie абстрагированы. Куки содержат идентификатор сессии, а не сами данные (если только вы не используете базовый модуль cookie).

Включение сессий

Сессии реализуются посредством компонента средства.

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

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

Если вы не хотите использовать сессии, удалите строку SessionMiddleware из MIDDLEWARE и 'django.contrib.sessions' из вашей INSTALLED_APPS. Это сэкономит небольшое количество накладных расходов.

Настройка движка сессий

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

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

Если вы хотите использовать сессию с поддержкой базы данных, вам необходимо добавить 'django.contrib.sessions' в ваш параметр INSTALLED_APPS.

После настройки вашей установки выполните manage.py migrate для установки единственной таблицы базы данных, которая хранит данные сессий.

Использование кэшированных сессий

Для повышения производительности вы можете использовать кэшированный механизм сессий.

Чтобы хранить данные сессий с помощью кэша Django, вам сначала нужно убедиться, что вы настроились на кэширование; см. документацию по кэшированию для получения подробностей.

Если в CACHES определено несколько кэшей, Django будет использовать кэш по умолчанию. Чтобы использовать другой кэш, установите SESSION_CACHE_ALIAS в имя этого кэша.

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

Кэшированный механизм с поддержкой базы данных (cached_db) использует кэш с пробросом записей — записи сессии применяются как к кэшу, так и к базе данных. Чтение сессии использует кэш или базу данных, если данные были удалены из кэша. Чтобы использовать этот механизм, установите SESSION_ENGINE на "django.contrib.sessions.backends.cached_db", и следуйте инструкциям по настройке для использования сессий с поддержкой базы данных.

Механизм кэша (cache) хранит данные сессии только в вашем кэше. Это быстрее, так как избегает сохранения в базе данных, но вам придется подумать о том, что произойдет при удалении данных из кэша. Удаление может произойти, если кэш заполнится или сервер кэша будет перезапущен, и это приведет к потере данных сессии, включая выход пользователей. Чтобы использовать этот механизм, установите SESSION_ENGINE на "django.contrib.sessions.backends.cache".

Механизм кэша может быть сделан постоянным с помощью постоянного кэша, например, Redis с соответствующей настройкой. Но, если ваш кэш не настроен на достаточную постоянность, выберите кэшированный механизм с поддержкой базы данных. Это поможет избежать проблем, возникающих из-за ненадежного хранения данных в рабочей среде.

Использование сессий на основе файлов

Чтобы использовать сессии на основе файлов, установите параметр 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.

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

Когда 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', 'blue')

keys()

items()

setdefault()

clear()

Также у него есть эти методы:

flush()

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

set_test_cookie()

Устанавливает тестовый cookie для определения возможности поддержки cookie браузером пользователя. Из-за работы cookie вы не сможете протестировать это до следующего запроса страницы пользователя. Дополнительную информацию см. в разделе «Установка тестовых cookie» ниже.

test_cookie_worked()

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

delete_test_cookie()

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

get_session_cookie_age()

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

set_expiry(value)

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

• Если value — целое число, сессия истечёт через указанное количество секунд бездействия. Например, вызов request.session.set_expiry(300) приведет к истечению сессии через 5 минут.
• Если value — объект datetime или timedelta, сессия истечёт в указанную дату/время.
• Если value равно 0, cookie сессии пользователя истечёт при закрытии веб-браузера пользователя.
• Если value равно None, сессия вернётся к использованию глобальной политики истечения срока действия сессии.

Чтение сессии не считается деятельностью для целей истечения срока действия. Истечение срока действия сессии рассчитывается с момента последнего изменения сессии.

get_expiry_age()

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

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

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

Примечание

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

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

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

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 (или любой ключ из SECRET_KEY_FALLBACKS) известен злоумышленнику (в Django нет внутренней уязвимости, которая могла бы привести к утечке), злоумышленник может вставить строку в свою сессию, которая при распаковке выполнит произвольный код на сервере. Техника для этого проста и легко доступна в интернете. Хотя хранилище сессий с cookie подписывает хранимые в cookie данные для предотвращения подделки, утечка SECRET_KEY сразу же перерастает в уязвимость удалённого выполнения кода.

Встроенные сериализаторы

class 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-сериализации см. в разделе Написание собственного сериализатора.

Написание собственного сериализатора

Обратите внимание, что 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.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.")

…И этот вид выполняет выход члена, согласно 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")

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

>>> 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. Если оно установлено в значение True, Django будет сохранять сессию в базе данных на каждом запросе.

Обратите внимание, что cookie сессии отправляется только при создании или изменении сессии. Если SESSION_SAVE_EVERY_REQUEST равно True, cookie сессии будет отправляться на каждом запросе.

Аналогично, часть cookie сессии expires обновляется каждый раз при отправке 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 с длиной жизни браузера — cookie, которые истекают сразу после закрытия браузера пользователем. Используйте это, если вы хотите, чтобы пользователи каждый раз должны были входить в систему при открытии браузера.

Это глобальное значение по умолчанию может быть перезаписано на уровне каждой сессии путём явного вызова метода set_expiry() объекта request.session, как описано выше в разделе использование сессий в представлениях.

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

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

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

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

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

Настройки

Несколько Настроек Django позволяют контролировать поведение сессий:

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

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

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

Например, злоумышленник может войти в 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 отправляет куки только если это необходимо. Если вы не устанавливаете данные сессии, куки сессии не будут отправлены.

Объект 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.

class base_session.AbstractBaseSession

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

session_key

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

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

Если вы мигрируете с встроенного хранилища сессий Django в пользовательское, основанное на cached_db, вы должны переопределить префикс ключа кэша, чтобы предотвратить конфликт имён пространств:

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

    # ...

Идентификаторы сессий в URL-адресах

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