image.png
1、传统单体架构 基于session的权限校验
image.png
1、保存用户信息 到 服务器内存,用于会话保持
2、jsessionId存储到浏览器的cookie里，登录后每次访问都要 带上这个，与用户信息绑定,如果jsessionId被人盗取,容易遭受csrf 跨域攻击。
3、如果登录用户过多, 服务内保存的session信息 占用内存较大
2、分布式session
由于项目组件的变大，往往会把 应用部署多份，再用nginx 做负载均衡，提高系统的并发量。
这时 由服务器来 存储session 就会出现出现问题：
image.png
- 第一次登录请求 负载均衡到 tomcat1 , 登录成功,.将会话信息保存在tomcat1
- 第二次请求 负载均衡到tomcat2, tomcat2没有存有会话信息,会被认为是 没有登录。
接下来就引入了 分布式session的 方案：
不讲 session信息存储在 服务器内部,引入第三方中间件如redis,mongodb,将session统一放到 第三方中间件这里，然后 再统一从 这取。
image.png
3、微服务项目 基于 Oauth2.0 的权限校验
3.1、权限校验方案
3.1.1、只在网关层做权限校验
image.png
因为在微服务应用中,网关是 系统 所有流量的入口。在网关中 进行权限校验，理论上是可行的。
当请求携带登录返回的token时, 请求网关, 由网关来 向认证服务器 发起 校验token 的请求。
- 如果认证服务器返回校验通过,则 继续路由到下游服务器
- 校验不通过, 则直接 返回 无权限。
ip白名单校验
但是这样还有一个很重要的问题, 就是下游服务 不做权限校验的话，那么 下游服务 的接口 就完全相当于裸奔的, 别人知道下游服务的接口地址，就可以直接调用, 非常的危险。
所以，在这种方案中,一般 还会加上ip白名单校验, 下游服务 只允许 网关 发过来的请求,其他 来源不明的请求,直接在防火墙 拦截调。以保证, 下游服务的接口 只能网关转发过来并且 是 网关鉴权通过的。
3.1.2、只在下游服务做权限校验。
image.png
理论上 网关 服务器是不需要进行权限校验的，因为 zuul 服务器没有接口， 不需要从 网关 调用业务接口，网关 只做简单的路由工作。下游系统在获取到 token 后，通过 过滤器把 token 发到认证服务器校验该 token 是否有效，如果认证服务器校验通过就会携带 这个 token 相关的验证信息传回给下游系统，下游系统根据这个返回结果就知道该 token 具 有的权限是什么了。
这种方式 不会有 接口裸奔的风险, 也不用加ip白名单校验,更可以 进行方法级别的校验,粒度更细。
3.2、缺点
不管 是只在网关层做权限校验,还是只在下游服务做权限校验,在oauth2.0的权限校验模型中, 所有 校验token的过程,都需要与 认证服务器 进行一次 交互, 这点 不太好,多了一次 网络请求。
网友评论