使用SignedCookieSessionFactory时,文档指出已使用sha512 HMAC摘要算法.结果,一旦会话数据被序列化,就将其签名并在会话cookie下发送给用户的客户端.
Pyramid的文档中没有提到会话也在服务器端缓存(在此SessionFactory下).
当与SessionAuthenticationPolicy配对时,这会带来矛盾并导致身份验证混乱.如果无法从客户端的会话cookie中检索会话数据(因为它是单向散列的),那么怎么可能做到以下几点？
>使用应用程序进行身份验证,以使读取Request.authenticated_userid不会返回None.
>将会话Cookie复制到剪贴板.
>通过访问一个视图注销,从而将来自forget(request)的标头返回到响应中.
>用复制的值替换会话cookie.
>用户现在重新登录.
我了解,仅删除Cookie客户端不足以完全使会话无效(不列入黑名单),但这会带来以下问题：
>除非以某种方式记住用户最近发出的每个会话cookie并将其列入黑名单/使它们无效,否则如何在浏览器范围的会话中保持安全？
>会话cookie实际上是否是用于在内存中查找会话的密钥/会话ID？因为它是单向签名,所以肯定是唯一的解释吗？
>那么是否有可能使服务器端的会话无效,而不仅仅是headers = forget(request)模式更强大？
最终,我想答案是这样的：
“使用诸如pyramid_redis_sessions之类的包含项来维护服务器端会话”
任何解释将不胜感激.
How is it possible to remain secure with browser-scoped sessions unless every session cookie the user has recently been issued is somehow remembered and blacklisted/invalidated?
这取决于您将会话用于什么目的-在将数据放入会话对象之前,您需要考虑这些问题.
Is it possible then to invalidate sessions server-side,a little more robust than just the headers=forget(request) pattern?
除非您在会话中存储某种ID,然后在服务器端黑名单ID表中存储它们,否则不会这样.如果执行此操作,则可以编写自己的包装器会话工厂,以打开该会话,检查ID并返回空白(如果已将其列入黑名单).当然,那么您可能只想使用服务器端会话库(例如pyramid_redis_sessions或pyramid_beaker)及其服务器端存储后端之一.