webapp2 Sessions: как сессии работают концептуально? - PullRequest
Новая
       36

webapp2 Sessions: как сессии работают концептуально?

0 голосов
/ 09 сентября 2018

Я хочу реализовать сессии в webapp2. Из исследования я нашел этот пример кода с использованием webapp2_extra.sessions и несколько статей, в которых упоминаются устаревшие или не поддерживаемые библиотеки сеансов.

В настоящее время мне не хватает знаний о том, как сессии работают концептуально. Это то, что я понимаю до сих пор:

  1. Мы можем включить dispatch() метод в обработчик запросов, который позволяет нам создавать / обновлять объект сеанса; именно на этапе входа в приложение создается сеанс. ( Вопрос : как хранится сессия? В памяти приложения или в хранилище данных?)
  2. Когда пользователь отправляет запрос приложению, метод dispatch () проверяет, существует ли для пользователя существующий сеанс. ( Вопрос : Как именно работает эта проверка? Есть ли токен внутри request.body или cookie, который ищут сеансы?)
  3. Когда пользователь выходит из системы, сеанс удаляется.

Правильно ли мое понимание? Или, может быть, мне не хватает чего-то важного? Похоже, в Интернете мало рекомендаций по этому вопросу. Спасибо за помощь.

1 Ответ

0 голосов
/ 10 сентября 2018

Технически метод dispatch() не добавляется, он просто перезаписывает тот, который webapp2.RequestHandler уже предоставляет, расширяя его для добавления поддержки сеанса. Если вы внимательно посмотрите на этот метод, вы увидите, что он по-прежнему вызывает исходный метод для фактической диспетчеризации: 

        # Dispatch the request.
        webapp2.RequestHandler.dispatch(self)

Который может быть переписан, если хотите, как: 

        super(BaseHandler, self).dispatch()

Все, что делает расширенный dispatch(), - это получает информацию о сеансе из хранилища, делая ее доступной для кода обработчика, перед отправкой запроса (который BTW включает в себя обработку запроса) и сохраняет его после этого, когда обработка запроса завершается. (когда возможно изменение информации о сеансе). Для каждого запроса! Просто способ сохранить информацию между запросами.

Поддержка сеанса проста: поддержка - ваше приложение по-прежнему отвечает за управление информацией, хранящейся в словаре сеанса webapp2, когда эта информация добавляется / изменяется / удаляется и как эта информация используется.

Другими словами webapp2 сам не имеет ни малейшего представления, что такое сеанс входа в систему / выхода из системы / пользователя и т. Д. (Поэтому нет, ничего, что вы упоминаете в # 1, # 2 и # 3, не происходит в самой webapp2). Ваше приложение отвечает за:

  • установка / удаление в словаре сеанса информации, представляющей ваш "пользовательский сеанс" (что бы это ни значило для вашего приложения) - обычно в обработчиках запросов на вход / выход пользователя, соответственно
  • используйте эту информацию по своему усмотрению при обработке входящих запросов между входом в систему и выходом из системы - когда информация из словаря сеансов представляет "текущий сеанс пользователя".

Для хранения информации о сеансе webapp2 поддерживает файлы cookie (по умолчанию), memcache и хранилище данных (ndb) . Из сессий:

Он имеет три встроенных бэкэнда: защищенные куки, memcache и хранилище данных. Новые бэкэнды могут быть добавлены, расширяя CustomBackendSessionFactory .

Хранилище сеансов может предоставлять несколько сеансов с использованием разных ключей, даже используя разные бэкэнды в одном запросе, через метод SessionStore.get_session () . По умолчанию он возвращает сессию, используя ключ по умолчанию из конфигурации.

...