本文主要是介绍B/S架构架构下 session请求的由Cooke换成请求头，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
替换Cookie会话保持换到自定义请求头
背景：应架构部要求，将APP的服务端用户体系，整体迁移的中台进行统一管理，统一使用中台的验证方式。以前APP使用的jwttoken，请求头采用oauth2的方式在请求中 Authorization=token进行验证，在gateway网关进行验证，这个应用已经和其他外部系统对接好了。因此这种 请求模式要求不能改变，否者对接的系统又要在对接一次。
思考：中台提供的是cookie中放置会话id，每次请求需要携带cookie，理论上和原来的方式在请求头中使用Authorization=token进行验证本质上没区别，都是验证这个人是否有权限去访问或者请求服务。
token与sessionId区别：
1、token和cookie一样都是首次登陆时，由服务器下发，都是当交互时进行验证的功能，作用都是为无状态的HTTP提供的持久机制。
2、token存在哪儿都行，localstorage或者cookie。
3、token和cookie举例，token就是说你告诉我你是谁就可以。
4、对于token而言，服务器不需要去查看你是谁，不需要保存你的会话。当用户logout的时候cookie和服务器的session都会注销；但是当logout时候token只是注销浏览器信息，不查库。
5、token优势在于，token由于服务器端不存储会话，所以可扩展性强，token还可用于APP中。
使用Sesssion考虑的问题：
由于session是时效的，而对于用户而言老登陆肯定是不行的。如何保持会话？
是否可以将cookie+sessionId会话的方式改成请求 Authorization=sessionId的方式？
思路：中台采用的是SpringSecurity进行的鉴权
1、第一种，使用拦截器拦截请求替换Authorization=sessionId 为cookie+sessionId 方式。
治标不治本，因此没有首先尝试。
2、第二种，重源头将请求方式统一换成Authorization=sessionId。
直接替换掉cookie方式，采用请求头方式更适合app的交互方式而且其他系统不需要改造
行动：
首先看了一遍平台才用那种登录方式，发现采用的是Security用户与密码模式，是在登录成功之后创建的session。
CookieHttpSessionIdResolver使用的这个实现来创建的，进入类发现
看到了 HttpSessionIdResolver 他是生成session的接口，提供了两种实现方式
一瞬间看到了希望，竟然还有头部的实现方式。马上进去看看源码
发现头部的方式提供了两种模式，往下一看哎，竟然能之定义，顿时心里就美滋滋的。
猜测是不是可以自定义一个配置将这个CookieHttpSessionIdResolver方式替换掉。于是就写了一个配置文件尝试了一下
之前app是在请求头中加的HttpHeaders里的如下的方式多为请求的头的key
启动系统尝试发现以前登录方式那不到cookie，自己使用http请求工具写了一个请求
发现在响应头的竟然有这个 Authorization=sessionId，于是我就尝试在拿着这个session在其他接口上进行尝试
成功了，这样其他的接口不需要在对接了。直接解决了根本问题。
关于失效的问题我们这头将session有效设置为24小时，每天第一次打开应用会刷新一次。
总计：
这种方式仅适用向我遇到这种情况，其他情况我不清楚是否适用
主要通过替换HttpSessionIdResolver的默认实现方式 CookieHttpSessionIdResolver为HeaderHttpSessionIdResolver
同时HeaderHttpSessionIdResolver之提供了自定义的头名的方式，可以根据需要自行定义。
自己写一个配置类进行替换。
这篇关于B/S架构架构下 session请求的由Cooke换成请求头的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
