Cookie и сессии: состояние между HTTP-запросами
HTTP-запросы независимы друг от друга — cookie и сессионные механизмы позволяют связать состояние между ними.
HTTP-запросы независимы друг от друга: сам по себе протокол не связывает один запрос
со следующим. Но приложению из раздела 22.29 уже нужно сохранять что-то между запросами —
например, сообщение об ошибке, которое должно появиться на следующей странице после
flash(...). Для этого существуют cookie и сессионные
механизмы.
Cookie — маленькое значение, которое хранит браузер
Cookie — небольшой кусочек данных, который сервер просит браузер сохранить, а браузер затем прикладывает к следующим запросам на тот же сайт. Именно так сервер может связать несколько запросов друг с другом как пришедшие от одного и того же браузера.
Сессия — механизм сохранения состояния между запросами
Сессия (session) — механизм уровня приложения, который использует
cookie, чтобы связать несколько запросов друг с другом и хранить между ними какие-то
данные. Реализации бывают разными: данные сессии можно хранить на сервере (в базе данных
или отдельном хранилище, а в cookie передавать только идентификатор), а можно — прямо в
самом cookie на стороне браузера. Flask по умолчанию использует второй вариант и
предоставляет готовый объект session, который ведёт себя как
словарь:
from flask import session
session["poslednij_vizit"] = "22-30"
# на следующем запросе того же браузера:
session.get("poslednij_vizit") # "22-30"
Функция flash(...), использованная в разделе 22.29, устроена
поверх того же механизма session: сообщение сохраняется в сессии на один следующий запрос
и автоматически стирается после того, как его прочитали через
get_flashed_messages() в шаблоне.
SECRET_KEY. Подпись гарантирует подлинность: если кто-то изменит содержимое cookie, подпись перестанет совпадать, и Flask отклонит такую сессию. Но подпись — не шифрование: содержимое сессии по умолчанию можно прочитать, не зная секретный ключ, — оно просто не поддаётся необнаруживаемому изменению. Никогда не кладите в сессию пароли или другие данные, которые должны оставаться нечитаемыми для пользователя, чей браузер их хранит.Проект этой главы намеренно останавливается здесь: полноценный вход пользователей (аутентификация) добавил бы главе объём отдельного курса. Где эта тема продолжается — в разделе 22.36.