替换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之提供了自定义的头名的方式,可以根据需要自行定义。
自己写一个配置类进行替换。