Ответ 1
Я делаю это, вызывая session.clear()
.
EDIT:
После прочтения вашего комментария в другом ответе я вижу, что вы пытаетесь предотвратить повторную атаку, которая может быть сделана с использованием файла cookie, который был выпущен в прошлом. Я решил эту проблему как можно больше * с помощью этого подхода:
- Переопределите SecureCookieSessionInterface.save_session(), скопировав код из переопределенной версии, а не вызывая его.
- Когда переопределенная версия
save_session()
вызываетsave_cookie()
, заставьте ее передать аргументsession_expires
30 минут в будущем. Это приводит к тому, что файлы cookie старше 30 минут считаются недействительными. - Сделать переопределенную версию
save_session()
обновлять переменную сеанса так часто, чтобы убедиться, что cookie и его времяsession_expires
регулярно переписываются. (Я называю эту переменную сеанса "_refresh" и сохраняю текущее время в ней, а затем переписываю ее, только если прошло более нескольких секунд с момента последнего сохранения. Эта оптимизация позволяет переписать cookie на каждый HTTP-запрос.)
Дублирующий код фляжки в пользовательском save_session()
делает этот подход немного уродливым и хрупким, но он необходим для изменения аргументов, переданных в save_cookie()
. Было бы неплохо, если бы Флакс сделал это проще или, по крайней мере, выполнил свою собственную защиту от атак с помощью повтора.
* ПРЕДУПРЕЖДЕНИЕ. Этот подход сам по себе не остановит повторные атаки, которые могут произойти во время срока действия cookie сеанса. Эта фундаментальная проблема с сессиями на основе файлов cookie обсуждается в RFC 6896 и Безопасный протокол cookie Лю, Ковач, Хуан, Гауда.