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之提供了自定义的头名的方式，可以根据需要自行定义。

自己写一个配置类进行替换。