Если сеансы Pyramid являются односторонним хэшированием и не сохраняются на стороне сервера, откуда поступают данные?

Question

При использовании SignedCookieSessionFactory в документации указывается, что используется алгоритм дайджеста sha512 HMAC.В результате этого после сериализации данных сеанса они подписываются и отправляются клиенту пользователя в файле cookie session.

В документации Pyramid не упоминается, что сеансы также кэшируются на стороне сервера (в соответствии с этим SessionFactory).

Это представляет противоречие и также приводит к путанице в аутентификации при соединении с SessionAuthenticationPolicy.Если данные сеанса не могут быть извлечены из файла cookie клиента session (поскольку он односторонне хешируется), как получается, что возможно следующее?

1. Аутентификация с приложением так, чточтение Request.authenticated_userid не возвращает None.

2. Скопируйте файл cookie session в буфер обмена.

3. Выйдите из системы, открыв окнов ответе возвращаются заголовки из forget(request).

4. Замените файл cookie session на скопированное значение.

5. Теперь пользовательснова вошел в систему.

Я понимаю, что простого удаления клиентской стороны cookie недостаточно для полной аннулирования сеанса (без внесения в черный список), но тогда возникают следующие вопросы:

• Как можно обеспечить безопасность сеансов в области браузера, если только каждый файл cookie сеанса, который недавно был выдан пользователю, каким-либо образом запоминается и помещается в черный / недействительный список?

• session cookie на самом деле идентификатор ключа / сеанса, который используется для поиска сеанса в памяти?Поскольку это односторонняя подпись, конечно, это единственное объяснение?

• Можно ли затем аннулировать сеансы на стороне сервера, чуть более надежные, чем просто шаблон headers=forget(request)?

В конечном счете, я полагаю, что ответ заключается в следующем: «Поддерживать сеансы на стороне сервера с использованием включения, такого как pyramid_redis_sessions»

Любое объяснение будет приветствоваться.

Answer 1

Файл cookie содержит все данные.Сам контент сеанса хранится в cookie вместе с сигнатурой hmac этого контента.Это означает, что клиент может просматривать контент, если он старается изо всех сил, но он не может изменить его, поскольку он не может создавать доверенные подписи без секрета на стороне сервера.

Как можно оставаться в безопасности сСессии в браузерной области, если каждый файл cookie сеанса, который недавно был выпущен пользователем, каким-то образом запоминается и заносится в черный список / становится недействительным?

Это зависит от того, для чего вы используете сеанс - вам необходимо принять во внимание эти проблемыперед помещением данных в объект сеанса.

Возможно ли затем аннулировать сеансы на стороне сервера, чуть более надежные, чем просто шаблон заголовков = Забыли (запросить)?

Нет, если вы не сохраните какой-либо идентификатор в сеансе, а затем на стороне сервера в таблице идентификаторов из черного списка.Если вы сделали это, то могли бы написать свою собственную фабрику-сессию оболочки, которая открывала сеанс, проверяла идентификатор и возвращала пустой, если он был в черном списке.Конечно, тогда вы можете просто использовать библиотеку сеансов на стороне сервера, такую ​​как pyramid_redis_sessions или pyramid_beaker, с одним из своих серверных хранилищ.