session expired что значит
Использование сессий ¶
Активация сессий ¶
Чтобы включить функцию сеансов, сделайте следующее:
Настройка механизма сеанса ¶
По умолчанию Django хранит сеансы в базе данных (с шаблоном django.contrib.sessions.models.Session ). Хотя это может быть удобно, в некоторых конфигурациях быстрее хранить данные сеанса в другом месте; поэтому можно настроить Django для хранения данных сеанса в файловой системе или в кеше.
Использование сессий в базе данных ¶
После настройки установки запустите для установки единой таблицы базы данных, в которой хранятся данные сеанса. manage.py migrate
Использование кешированных сессий ¶
Для лучшей производительности рекомендуется использовать механизм сеанса на основе кеша.
Чтобы хранить данные сеанса с использованием системы кеширования Django, вам сначала нужно убедиться, что кеш настроен; см. документацию по кешу для получения более подробной информации.
Данные сеанса следует кэшировать только при использовании механизма кэширования Memcached. Механизм кеширования локальной памяти не хранит данные достаточно долго, чтобы быть хорошим выбором, и быстрее использовать механизм сеанса на основе файлов или баз данных напрямую, чем передавать их через все с помощью механизмов кэширования на основе файлов или баз данных. Кроме того, механизм кэширования локальной памяти НЕ обрабатывает многопроцессорный режим должным образом и поэтому, вероятно, не является хорошим выбором в производственной среде.
После настройки кеша у вас есть два варианта хранения данных в кеше:
Использование файловых сессий ¶
Также может быть желательно установить параметр SESSION_FILE_PATH (значение по умолчанию для которого tempfile.gettempdir() обычно является результатом /tmp ), чтобы контролировать, где Django хранит файлы сеанса. Убедитесь, что у веб-сервера есть разрешения на чтение и запись.
Использование сессий на основе файлов cookie ¶
Рекомендуется оставить параметр SESSION_COOKIE_HTTPONLY равным значению, True чтобы предотвратить доступ к сохраненным данным из JavaScript.
Если вы используете сеансы на основе файлов cookie, следует проявлять особую осторожность, чтобы всегда держать секретный ключ в абсолютном секрете для любой системы с удаленным доступом.
** данные сеанса подписаны, но не зашифрованы **
При использовании механизма на основе файлов cookie данные сеанса могут быть прочитаны клиентом.
MAC-код (код проверки подлинности сообщения) используется для защиты данных от модификации клиентом, поэтому данные сеанса недействительны, когда они были изменены. Такая же защита происходит, если клиент, который хранит cookie (например, браузер пользователя), не может сохранить весь файл cookie сеанса и усекает данные. Несмотря на то, что Django сжимает данные, все же возможно превышение обычный лимит 4096 байт на файл cookie.
Нет гарантии свежести
Производительность
Использование сессий в представлениях ¶
Вы можете читать и писать в него request.session в любое время, когда вам будет удобно. Вы можете изменить его несколько раз.
класс backends.base. SessionBase ¶
Это базовый класс для всех объектов сеанса. Он имеет следующие стандартные словарные методы:
Пример: request.session[‘fav_color’] = ‘blue’
Пример: ‘fav_color’ in request.session
Пример: fav_color = request.session.get(‘fav_color’, ‘red’)
Пример: fav_color = request.session.pop(‘fav_color’, ‘blue’)
keys () ¶ items () ¶ setdefault () ¶ clear () ¶
Также есть следующие методы:
Удаляет данные для текущего сеанса и удаляет файл cookie сеанса. Это полезно для обеспечения того, чтобы данные предыдущего сеанса больше не могли воспроизводиться браузером пользователя (например, он это делает django.contrib.auth.logout() ).
Создает тестовый файл cookie, чтобы определить, поддерживает ли браузер пользователя файлы cookie. Из-за того, как работают файлы cookie, вы не сможете определить это до следующего запроса пользователя. См. Раздел Создание тестовых файлов cookie ниже для получения дополнительной информации.
Удалите тестовый файл cookie. Используется для уборки позади вас.
Определяет, как долго истекает сеанс. Можно передать несколько разных значений:
Чтение сеанса не считается занятием с точки зрения истечения срока действия. Срок действия сеанса исчисляется с момента последнего изменения сеанса.
Эта функция принимает два необязательных именованных параметра:
Возвращает True или в False зависимости от того, истекает ли срок действия cookie сеанса пользователя при закрытии веб-браузера пользователя или нет.
Создает новый ключ сеанса с сохранением данных текущего сеанса. django.contrib.auth.login() вызывает этот метод для борьбы с атаками фиксации сеанса.
Сериализация сессий ¶
Например, вот сценарий атаки, если вы используете pickle для сериализации данных сеанса. Если вы используете механизм сеанса на основе подписанных файлов cookie и ключ SECRET_KEY известен злоумышленнику (в Django нет известной уязвимости, которая раскрыла бы эту информацию), этот злоумышленник может вставить строку в сеанс, это что может привести во время десериализации («распаковки») к выполнению произвольного кода на сервере. Техника для этого проста и легко доступна в Интернете. Даже если файлы cookie хранилища сеанса подписывают данные сеанса, чтобы предотвратить подделку, раскрытие ключа SECRET_KEY немедленно создает уязвимость удаленного выполнения кода.
Встроенные сериализаторы ¶
Кроме того, поскольку JSON поддерживает только текстовые ключи, имейте в виду, что нетекстовые ключи в request.session не будут работать должным образом:
Точно так же данные, которые не могут быть закодированы в JSON, такие как байты, отличные от UTF-8, такие как ‘\xd9’ (который производит UnicodeDecodeError ), не могут быть сохранены.
Подробную информацию об ограничениях сериализации JSON см. В разделе « Написание собственного сериализатора».
класс serializers. PickleSerializer ¶
Принимает любой объект Python, но, как объяснено выше, может привести к уязвимости удаленного выполнения кода, если ключ SECRET_KEY будет раскрыт злоумышленнику.
Написание собственного сериализатора ¶
Класс сериализации должен реализовывать два метода и для сериализации и десериализации словаря данных сеанса соответственно. dumps(self, obj) loads(self, data)
Рекомендации для объектов сеанса ¶
Примеры ¶
Это очень простое представление подключает «участника» сайта:
. и это отключает член, учитывая приведенный login() выше пример :
Создание тестовых файлов cookie ¶
Для удобства Django предоставляет способ проверить, принимает ли браузер пользователя файлы cookie. Вызов метода set_test_cookie() из request.session в представлении, а затем вызвать test_cookie_worked() в одном из следующих представлений, но не в том же виде вызова.
Это странное разделение между set_test_cookie() и test_cookie_worked() необходимо из-за того, как работают файлы cookie. Когда вы устанавливаете файл cookie, на самом деле невозможно узнать, принял ли его браузер до получения следующего запроса браузера.
Рекомендуется использовать delete_test_cookie() для уборки позади вас. Сделайте это, убедившись, что тестовый файл cookie работает.
Вот пример типичного использования:
Использование сессий вне представлений ¶
Доступен API для управления данными сеанса вне представлений:
Обратите внимание, что вам нужно будет позвонить, get_decoded() чтобы получить словарь сеанса. Это необходимо, потому что словарь хранится в закодированном формате:
Запись сеансов ¶
По умолчанию Django сохраняет сеанс в базе данных только тогда, когда сеанс был изменен, то есть по крайней мере одно из значений в его словаре было установлено или удалено:
В последнем случае приведенного выше примера мы можем явно сообщить объекту сеанса, что он был изменен, установив его атрибут modified :
Аналогичным образом, часть expires файла cookie сеанса обновляется каждый раз при отправке файла cookie сеанса.
Сеанс не сохраняется, если код состояния ответа 500.
Истечение или сохранение сеанса ¶
Этот параметр SESSION_EXPIRE_AT_BROWSER_CLOSE позволяет вам контролировать тип сеансов, используемых инфраструктурой сеансов: сеансы, срок действия которых истекает при закрытии браузера, или постоянные сеансы.
Очистка хранилища сеансов ¶
По мере того, как все больше пользователей создают новые сеансы на вашем веб-сайте, данные о сеансах накапливаются в вашем хранилище сеансов. Если вы используете движок в качестве базы данных, таблица базы данных django_session увеличивается. Если вы используете файловый движок, количество файлов во временном каталоге будет постоянно увеличиваться.
Обратите внимание, что механизм на основе кеша не подвержен этой проблеме, поскольку кеши автоматически удаляют устаревшие данные. То же самое и с движком на основе файлов cookie, поскольку данные сеанса хранятся в браузерах пользователей.
Настройки ¶
Некоторые настройки Django позволяют контролировать поведение сессий:
Безопасность сеанса ¶
Поддомены сайта могут устанавливать файлы cookie для клиента, действительные для всего домена. Это делает возможными атаки фиксации сеанса, если файлы cookie могут быть созданы субдоменами, которые не находятся под контролем доверенных лиц.
Технические детали ¶
Объект SessionStore ¶
Все классы, SessionStore доступные в Django, наследуются от SessionBase методов управления данными и реализуют их, в данном случае:
Можно расширить существующие механизмы сеанса, но для движков на базе баз данных это обычно требует немного больше работы (подробности читайте в следующем разделе).
Расширение движков сессий на основе баз данных ¶
класс base_session. AbstractBaseSession ¶
Базовая абстрактная модель сеанса.
Первичный ключ. Само поле может содержать до 40 символов. Текущая реализация генерирует 32-символьную строку (случайную последовательность строчных цифр и букв ASCII).
Строка, содержащая закодированный и сериализованный словарь сеанса.
Дата / время, указывающие дату окончания сеанса.
Возвращает класс хранения сеанса для использования с этим шаблоном сеанса.
Возвращает декодированные данные сеанса.
Декодирование выполняется классом хранения сеанса.
Вы также можете настроить диспетчер моделей, унаследовав от BaseSessionManager :
класс base_session. BaseSessionManager ¶ encode ( session_dict ) ¶
Возвращает указанный словарь сеанса в виде закодированной и сериализованной строки.
Кодирование выполняется классом хранения сеанса, связанным с классом шаблона.
Сохраните данные сеанса, соответствующие указанному ключу сеанса, или удалите сеанс, если данные пусты.
Настройка классов SessionStore выполняется путем перегрузки методов и свойств, описанных ниже:
класс backends.db. SessionStore ¶
Реализация хранилища сессий на базе базы данных.
Переопределите этот метод, чтобы при необходимости возвращать настраиваемый шаблон сеанса.
Возвращает новый экземпляр объекта шаблона сеанса, который представляет текущее состояние сеанса.
Переопределив этот метод, вы можете изменить данные шаблона сеанса до их сохранения в базе данных.
класс backends.cached_db. SessionStore ¶
Реализация хранилища сеансов на основе базы данных и кеша.
Префикс, добавляемый к ключу сеанса для построения цепочки ключей кеша.
Пример ¶
В приведенном ниже примере показан настраиваемый механизм сеанса, управляемый базой данных, включая дополнительный столбец базы данных для хранения идентификатора учетной записи (и, таким образом, предоставляя возможность запрашивать базу данных для всех активные сеансы учетной записи):
Идентификаторы сеанса в URL ¶
Инфраструктура сеансов Django полностью основана на файлах cookie. Он не использует систему идентификаторов сеансов в URL-адресах, как это делает PHP. Это добровольное концептуальное решение. Этот метод искажает URL-адреса и делает ваш сайт уязвимым для кражи идентификатора сеанса через заголовок «Referer».
Совершенствуем контроль сессий в Spring Security
Добрый день, уважаемое Сообщество.
Разрабатывая многопользовательское web-приложение, столкнулся с проблемой многократного входа в систему (новый login при незавершенной старой сессии), решение которой потребовало необычного обходного маневра, чтобы сохранить логичную работу программы и ее понятный дизайн. В этой статье хочу поделиться c Вами опытом, осветив сперва традиционные подходы к управлению сессиями в Spring Security, и завершив обзор рацпредложением в виде ‘костыля’ собственной разработки.
Проблема контроля сессий актуальна для множества проектов. В моем случае это была игра (бэкенд на Java+Spring), где зарегистрировавшиеся пользователи могут выбирать с кем сразиться из списка присутствующих на сайте свободных игроков. После входа (login) игрока информация о нем добавляется в структуру данных в памяти. Часть этих данных асинхронно отображается в игровом интерфейсе, как список игроков, присутствующих на арене. Когда игрок выходит, то информация о нем должна быть сохранена в БД, удалена из структуры данных, и игрок более не будет отображаться в списке соперников online. Здесь возникали некоторые трудности из-за асинхронности, но не будем затрагивать их, ведь они лежат в стороне от темы статьи.
Остановимся подробнее на стратегии управления самыми различными ситуациями, связанными с login и logout. Прежде всего нужно было учесть то, что выход игрока с арены может произойти в результате таких его действий:
Уходим по-аглийски
Для таких ‘английских’ сценариев используется следующий подход.
1. Добавляется SessionEventListener при регистрации DispatcherServlet в ходе стандартной инициализации и настройки Spring MVC приложения:
2. Реализуется слушатель событий сессии:
3. Добавляется SessionRegistry в конфигурацию Spring Security:
Теперь, благодаря тому, что мы устанавливаем таймаут ‘event.getSession().setMaxInactiveInterval(60*10)’ для каждой новой сессии (в SessionEventListener ), у нас любой сценарий выхода по-английски будет приводить к тому, что через короткое время (у нас в примере — 10 минут) сессия становится expired. Сразу же будет выброшено событие sessionDestroyed, оно будет обработано слушателем, который вызовет соотвествующий сервис для удаления игрока с арены, сохранения его persistent данных, очистки кэшей и т.п. То, что мы и хотели. Разместив всю эту логику в единственном методе, вызываемом из обработка sessionDestroyed, мы значительно упрощаем дизайн.
Логинищимуся — свободу выбора
До сих пор Spring Security демонстрировал необходимую гибкость. Но вот тут возникло желание точно также учесть различные варианты поведения пользователя при авторизации. Так, игрок может:
Что предлагает в данном случае стандартный подход Spring Security. Установить при конфигурации следующие свойства:
Это как раз не устаивало. Так как такое поведение Spring Security было подобно превентивной ядерной бомбардировке. Игрок возможно по ошибке логиниться повторно, и его прошлая игра без предупреждения прекращается. Необходимо было доработать этот сценарий, чтобы для игрока было показано предупреждающее окно с возможность выбора:
Теперь в результате настройки ‘.maxSessionsPreventsLogin(true)’ повторный логин игрока при незакрытой прошлой сессии приводит к определенней в Spring Security исключительной ситуации SessionAuthenticationException. Нам следует только обработать ее и перенаправить пользователя на html страницу с предупреждением, которая, кроме того, задает выбор: а) не продолжать и вернуться к прошлой открытой сессии (где возможно идет игра); б) все-таки залогиниться и тогда прошлая сессия должна быть убита.
Обработчик такой исключительной ситуации регистрируется при конфигурации Spring Security как ‘.failureHandler(new SecurityErrorHandler())’, а сам класс обработчика реализуется следующим образом:
Позволь, я отрублю сессии голову
Хотя такой подход неоднократно описан в сообществе Spring Security, он имеет существенный недостаток. При его реализации не происходит интуитивно ожидаемого действия. Сессия конечно же объявляется устаревшей (expired), но не закрывается. Другими словами, сессия не будет уничтожена (destroyed), после того, как мы вручную вызвали для нее рекомендованный expireNow(). А значит:
Загнанные сессии пристреливают, не правда ли?
Почему так происходит. Вызов метода expireNow() у объекта SessionInformation просто напросто устанавливает значение его поля expired=true. Никаких других действий не выполняется и не должно выполняться. Только когда пользователь из своей устаревшей сессии отправит какой-либо новый HTTP запрос, то тогда эта expired сессия будет убита, а пользователь увидит, как в его браузере произошел редирект на страницу ввода login, обработает событие sessionDestroyed (ожидаемое поведение). Это связано с тем, что: а) уничтожением сессии занимается контейнер сервлетов и делает он это в данном случае после получения нового HTTP запроса; б) функционал Spring Security реализованный за счет цепочек фильтров (Java Servlet Filter) без получения запроса ничего не выполняет; в) добавленный нами к сервлету слушатель SessionEventListener обработает событие sessionDestroyed тоже вследствие нового HTTP запроса.
Рекомендованный многими, включая Spring документацией, метод для контроля сессий ‘expireNow()’, таким образом, работает вопреки наивным ожиданиям. В нашим случае это нарушало синхронность приложения. Важно, что повторный логин после ‘expireNow()’ уже возможен, так как контроль сессий Spring Security разрешает это после того, как прошлая сессия была объявлена expired=true (исключения SessionAuthenticationException уже не выбрасываются). Spring документация говорит об этом достаточно поверхностно. При этом прошлая сессия фактически не уничтожена, событие sessionDestroyed не обработано, соответственно, информация об игроке, который ожидает, что он вышел (чтобы возможно заново залогиниться), не сохранена. Игра (как и чат или другое интерактивное приложение) посылают сообщения в старую сессию и т.п. Если игрок теперь залогинится заново произойдет хаос в связи с конкурентным созданием новой сессии и отработкой sessionDestroyed, разбираться с которым можно тяжеловесными threadsafe инструментами. Но можно все сделать проще.
Чтобы исправить эту ситуацию и сделать логику повторного логина и закрытия старой сессии более предсказуемой был использован следующий подход. В наш SessionService (бин назван как ‘expireUsereService’) мы добавляем следующий метод:
Благодаря вызову этого метода мы симулируем http запрос от пользователя, сессия которого была нами же помечена как устаревшая. Лучше вызвать ‘killExpiredSessionForSure(id)’ сразу после ‘expireNow()’, тогда будет происходить желаемое поведение:
Итоги подведем
В общем, благодаря этому приложение стало работать интуитивно понятнее, и задумки по его дизайну реализовались. Идея, которая заключалась в том, чтобы разместить весь код, обновляющий данные про online пользователей и сохраняющий данные пользователей, любым способом вышедших из системы, в обработчике события sessionDestroyed, оказалась здравой. Для ее корректной реализации потребовалось только создать дополнительный механизм разрушения expired сессий, который и описан в заключении данной статьи.
Кроме того, данный подход, то есть использование комбинации вызова методов — общеизвестного ‘expireNow()’ и предложенного ‘killExpiredSessionForSure(String id), можно использовать и в таких случаях:
Примечание
* — Переход происходит благодаря коду на фронтенде. В нашем случае текущие сообщения в ходе игры передаются с помощью WebSocket. WebSocket использует HTTP протокол (модифицированный) только для установления соединения, а затем обменивается сообщениями по своему WebSocket протоколу, работающему поверх TCP. Соответственно обмен этими сообщениями не фильтруется Servlet Filter вообще и цепочкой фильтров Spring Security в частности. Поэтому даже в просроченной (expired) сессии до нашего совершенствования шел обмен игровыми сообщениями. Передача таких сообщений не приводила к уничтожению expired сессии. Так возникала иллюзия продолжения игры там, где этого не должно было быть. Но если сессия окончательно уничтожена (с помощью вызова killExpiredSessionForSure(id)), то автоматически разрывается и WebSocket соединение. Фронтендовый код замечает это (при разрыве WebSocket соединения выполняется заданный callback) и переходит на home/login-page страницу. Это способ позволяет прервать WebSocket соединение бэкендом, так как реализация Stomp в Spring из коробки не имеет API для разрыва WebSocket сессии со стороны сервера.
Документация Django 1.9
Django полностью поддерживает сессии для анонимных пользователей, позволяет сохранять и получать данные для каждой посетителя сайта. Механизм сессии сохраняет данные на сервере и самостоятельно управляет сессионными куками. Куки содержат ID сессии, а не сами данные (если только вы не используете бэкенд на основе кук ).
Активируем сессии¶
Чтобы активировать сессии, выполните следующие действия:
Настройка сессий¶
По умолчанию, Django хранит сессии в базе данных (используя модель django.contrib.sessions.models.Session ). В некоторых случаях лучше хранить данные сессии в других хранилищах, поэтому Django позволяет использовать файловую систему или кэш.
Использование базы данных для хранения сессии¶
Использование кэша для хранения сессии¶
Для улучшения производительности вы можете использовать кэш для хранения сессии.
Для этого вы должны настроить кэш, смотрите раздел о кэше.
Вам следует использовать кэш только при использовании Memcached. Кэш в памяти не хранит данные достаточно долго, и лучше использовать файлы или базу данных для сессии, чем каждый раз обращаться к кэшу в файловой системе или базе данных. Также кэш в памяти использует различные экземпляры кэша для разных процессов.
После настройки кэша у вас есть две опции, определяющие как хранить данные в кэше:
Использование файловой системы для хранения сессии¶
Хранение сессии в куках¶
Если вы храните сессию в куках, храните ваш секретный ключ максимально надежно для всех систем, которые используются пользователем.
Сессионные данные подписаны, но не закодированы
Клиент может прочитать данные сессии, если вы храните их в куках.
Актуальность не гарантируется
Производительность
Наконец, размер кук может повлиять на производительность вашего сайта.
Использование сессии в представлениях¶
Вы можете читать и менять request.session в любом месте вашего представления множество раз.
class backends.base. SessionBase ¶
Это базовый класс для всех объектов сессии. Он предоставляет набор стандартных методов словаря:
Например: fav_color = request.session[‘fav_color’]
Например: request.session[‘fav_color’] = ‘blue’
Например: ‘fav_color’ in request.session
Например: fav_color = request.session.get(‘fav_color’, ‘red’)
Example: fav_color = request.session.pop(‘fav_color’, ‘blue’)
keys ()¶ items ()¶ setdefault ()¶ clear ()¶
Также содержит следующие методы:
Deletes the current session data from the session and deletes the session cookie. This is used if you want to ensure that the previous session data can’t be accessed again from the user’s browser (for example, the django.contrib.auth.logout() function calls it).
Удаление сессионной куки было добавлено в Django 1.8. Ранее значение сессионной куки менялось и отправлялось пользователю в куках.
Устанавливает тестовую куку, чтобы проверить, что браузер пользователя поддерживает куки. Из-за особенностей работы кук вы не сможете проверить тестовую куку, пока пользователь не запросит следующую страницу. Подробности смотрите ниже ( `Setting test cookies`_ ).
Удаляет тестовую куку. Используйте, чтобы убрать за собой.
Указывает время жизни сессии. Вы можете передать различные значения:
Если value целое число, сессия истечет после указанного количества секунд неактивности пользователя. Например, request.session.set_expiry(300) установит время жизни равное 5 минутам.
Чтение сессии не обновляет время жизни сессии. Время жизни просчитывается с момента последнего изменения.
Функция понимает два необязательных именованных аргумента:
Возвращает дату окончания действия сессии. Для сессий, у которых дата завершения не указана (или которые завершаются при закрытии браузера), значением будет дата, отстоящая на SESSION_COOKIE_AGE секунд от текущего момента.
Создает новый ключ сессии при сохранении текущих данных в ней. Функция django.contrib.auth.login() вызывает этот метод, чтобы противодействовать фиксации сессии.
Сериализация сессии¶
For example, here’s an attack scenario if you use pickle to serialize session data. If you’re using the signed cookie session backend and SECRET_KEY is known by an attacker (there isn’t an inherent vulnerability in Django that would cause it to leak), the attacker could insert a string into their session which, when unpickled, executes arbitrary code on the server. The technique for doing so is simple and easily available on the internet. Although the cookie session storage signs the cookie-stored data to prevent tampering, a SECRET_KEY leak immediately escalates to a remote code execution vulnerability.
Поставляемые сериализации¶
Следует отметить, что раз JSON поддерживает только строки в качестве ключей, то использование других типов данных в этом качестве в request.session приведёт к неожиданным результатам:
Обратитесь к разделу Реализация своего сериализатора для получения подробностей по возможностям сериализации в JSON.
class serializers. PickleSerializer ¶
Поддерживает произвольные объекты Python, но, как было указано выше, может привести к несанкционированному исполнению чужого кода на сервере в случае, если значение параметра конфигурации SECRET_KEY станет известно злоумышленнику.
Реализация своего сериализатора¶
Рекомендации для объекта сессии¶
Ключи словаря сессии, которые начинаются с подчёркивания зарезервированы для внутреннего использования Django.
Не перекрывайте request.session новым объектом, не меняйте его атрибута. Пользуйтесь им как обычным словарём Python.
Примеры¶
Простейшее представление устанавливает переменную has_commented в True после того, как пользователь отправит комментарий. Это не позволяет пользователю отправлять комментарий более одного раза:
Это простейшее представление авторизует пользователя сайта:
. А это обеспечивает выход пользователя, аналогично login() выше:
Установка проверочных кук¶
Для удобства Django представляет простой способ проверить принимает ли браузер пользователя куки или нет. Просто вызовите метод set_test_cookie() объекта request.session в предоставлении и затем вызовите метод test_cookie_worked() в следующем вызове представления, это важный момент.
Такое неудобное разделение set_test_cookie() и test_cookie_worked() между вызовами предоставления необходимо из-за особенностей работы механизма кук. Когда вы устанавливаете куку, вы не можете гарантировать, что браузер действительно принял куке до тех пор, пока браузер не выполнит следующий запрос.
Хорошим тоном будет использование метода delete_test_cookie() для очистки куки после проверки. Очистку следует выполнять после окончания этапа проверки наличия поддержки кук.
Покажем типичный вариант использования:
Использование сессий вне представлений¶
Для манипуляции данными сессии вне представления доступно API:
Для затруднения атак, направленных на фиксацию сессии, ключи сессий генерируются заново в случае их отсутствия:
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:
Когда сохраняются сессии¶
Обычно Django выполняет сохранение в базу данных сессии только в случае внесения изменений в сессию, то есть при назначении или удалении значений словаря:
В последнем случае вышеприведённого примера мы можем явно указать объекту сессии, что он был модифицирован, для этого надо у него установить атрибут modified :
Аналогично, значение атрибутп expires сессионной куки обновляется при каждой её отправке.
Сессия не сохраняется, если отклик имеет статус 500.
Разница между временными и постоянными куками¶
Очистка хранилища сессии¶
По мере создания пользователями новых сессий на вашем сайте в хранилище сессий накапливаются данные этих сессий. При использовании базы данных в качестве хранилища, таблица django_session постепенно наполняется. При использовании файлов в качестве хранилища, временный каталог будет содержать всё больше и больше файлов.
Следует отметить, что хранилище на основе кэша не подтверждено этой проблеме так как кэш автоматически удаляет устаревшие данные. Так же нет проблемы и с хранилищем на основе кук, потому что они хранятся в браузерах у пользователей.
Параметры конфигурации¶
Несколько параметров конфигурации Django представляют вам управление поведением сессии:
Безопасность сессии¶
Поддомены внутри сайта имеют возможность устанавливать куки на клиенте для всего домена. Это приводит к возможности фиксации сессии, если куки принимаются от поддоменов, которые не находятся под управлением доверенных пользователей.
Технические детали¶
Django отправляем куки только когда это требуется. Если вы не сохранили никаких данных в сессию, то сессионная кука не будет отправляться.
The SessionStore object¶
All SessionStore classes available in Django inherit from SessionBase and implement data manipulation methods, namely:
In order to build a custom session engine or to customize an existing one, you may create a new class inheriting from SessionBase or any other existing SessionStore class.
Extending most of the session engines is quite straightforward, but doing so with database-backed session engines generally requires some extra effort (see the next section for details).
Extending database-backed session engines¶
Creating a custom database-backed session engine built upon those included in Django (namely db and cached_db ) may be done by inheriting AbstractBaseSession and either SessionStore class.
class base_session. AbstractBaseSession ¶
The abstract base session model.
Primary key. The field itself may contain up to 40 characters. The current implementation generates a 32-character string (a random sequence of digits and lowercase ASCII letters).
A string containing an encoded and serialized session dictionary.
A datetime designating when the session expires.
Expired sessions are not available to a user, however, they may still be stored in the database until the clearsessions management command is run.
Returns a session store class to be used with this session model.
Returns decoded session data.
Decoding is performed by the session store class.
You can also customize the model manager by subclassing BaseSessionManager :
class base_session. BaseSessionManager ¶
Returns the given session dictionary serialized and encoded as a string.
Encoding is performed by the session store class tied to a model class.
save (session_key, session_dict, expire_date)¶
Saves session data for a provided session key, or deletes the session in case the data is empty.
Customization of SessionStore classes is achieved by overriding methods and properties described below:
class backends.db. SessionStore ¶
Implements database-backed session store.
Override this method to return a custom session model if you need one.
Returns a new instance of the session model object, which represents the current session state.
Overriding this method provides the ability to modify session model data before it’s saved to database.
class backends.cached_db. SessionStore ¶
Implements cached database-backed session store.
A prefix added to a session key to build a cache key string.
Example¶
The example below shows a custom database-backed session engine that includes an additional database column to store an account ID (thus providing an option to query the database for all active sessions for an account):