DefaultCookieSerializer到底能做什么?我认为它会在创建cookie时对其进行编辑,这就是将cookie存储在Redis中的方式。因此,如果以这种方式进行设置,则在创建此cookie后对它的任何使用都应附加jmvRoute。
首先,重要的是要意识到cookie本身没有存储在会话存储中(即您的Redis)。存储的是会话本身及其属性的表示。
除了会话存储之外,会话管理的另一个重要方面是用户的HTTP请求与存储的会话之间的关联。有了Spring Session的Servlet API支持,这是它的责任HttpSessionIdResolver
,并且默认情况下,Spring Session使用基于cookie的实现,即CookieHttpSessionIdResolver
。中还有一个基于HTTP标头的实现HeaderHttpSessionIdResolver
。我之所以这样说是因为,重要的是要意识到会话存储是在不同级别上运行的独特关注点。
现在,关于CookieHttpSessionIdResolver
,它将cookie的编写和读取问题委托给CookieSerializer
(DefaultCookieSerializer
默认情况下是……)。根据其配置,DefaultCookieSerializer
在写入和读取会话cookie时会考虑许多选项,例如cookie名称,是否对Base64编码cookie值,是否使用httpOnly
cookie指令等。
但是,我无法获得服务器关联性,因为调试Spring应用程序中的HttpServletRequest时,HttpServletRequest.getSession()。getId()中没有jvmRoute(尽管十六进制数字与我在Chrome中看到的匹配) ),这就是我转交给塔伦德工作的目的。
这是我不理解的部分- 如果您能够HttpSession
从当前的情况下解决问题,HttpServletRequest
那么您知道jvmRoute
它必然会正确吗?这是jvmRoute
当前JVM的,否则会话将无法HttpServletRequest
在此JVM的处理下解决。
什么是spring会议和Tomcat的会话管理之间的不同,是在Tomcat中jvmRoute
是会话ID生成相关的问题,而与spring会议将jvmRoute
在会话cookie序列化的环境中使用。