分布式系统--感性认识JWT
很久没写博客了，由于最近公司要求我学spring cloud ，早点将之前软件迁移到新的架构上。因此我那个拼命的学呐，老是图快，不少关键的笔记没有作好记录，如今又遗忘了不少关键的技术点，极其罪恶！javascript
如今想想，仍是踏踏实实的走比较好。这不，今天我冒了个泡，来补一补前面我所学所忘的知识点。java
想要解锁更多新姿式？请访问个人博客。git
常见的认证机制
今天我么聊一聊JWT。github
关于JWT，相信不少人都已经看过用过，他是基于json数据结构的认证规范，简单的说就是验证用户登没登录的玩意。这时候你可能回想，哎哟，不是又那个session么，分布式系统用redis作分布式session，那这个jwt有什么好处呢？web
请听我慢慢诉说这历史！redis
最原始的办法--HTTP BASIC AUTH
HTTP BASIC auth，别看它名字那么长那么生，你就认为这个玩意很高大上。其实原理很简单，简单的说就是每次请求API的时候，都会把用户名和密码经过restful API传给服务端。这样就能够实现一个无状态思想，即每次HTTP请求和之前都没有啥关系，只是获取目标URI，获得目标内容以后，此次链接就被杀死，没有任何痕迹。你可别一听无状态，正是如今的热门思想，就以为很厉害。其实他的缺点仍是又的，咱们经过http请求发送给服务端的时候，颇有可能将咱们的用户名密码直接暴漏给第三方客户端，风险特别大，所以生产环境下用这个方法不多。算法
Session和cookie
session和cookie老生常谈了。开始时，都会在服务端全局建立session对象，session对象保存着各类关键信息，同时向客户端发送一组sessionId，成为一个cookie对象保存在浏览器中。spring
当认证时，cookie的数据会传入服务端与session进行匹配，进而进行数据认证。sql
此时，实现的是一个有状态的思想，即该服务的实例能够将一部分数据随时进行备份，而且在建立一个新的有状态服务时，能够经过备份恢复这些数据，以达到数据持久化的目的。数据库
缺点
这种认证方法基本是如今软件最经常使用的方法了，它有一些本身的缺点：
- 安全性。cookies的安全性很差，攻击者能够经过获取本地cookies进行欺骗或者利用cookies进行CSRF攻击。
- 跨域问题。使用cookies时，在多个域名下，会存在跨域问题。
- 有状态。session在必定的时间里，须要存放在服务端，所以当拥有大量用户时，也会大幅度下降服务端的性能。
- 状态问题。当有多台机器时，如何共享session也会是一个问题，也就是说，用户第一个访问的时候是服务器A，而第二个请求被转发给了服务器B，那服务器B如何得知其状态。
- 移动手机问题。如今的智能手机，包括安卓，原生不支持cookie，要使用cookie挺麻烦。
Token认证（使用jwt规范）
token 即便是在计算机领域中也有不一样的定义，这里咱们说的token，是指 访问资源的凭据 。使用基于 Token 的身份验证方法，在服务端不须要存储用户的登陆记录。大概的流程是 这样的：
- 客户端使用用户名跟密码请求登陆
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 之后能够把它存储起来，好比放在 Cookie 里
- 客户端每次向服务端请求资源的时候须要带着服务端签发的 Token
- 服务端收到请求，而后去验证客户端请求里面带着的 Token，若是验证成功，就向客户端返回请求的数据
Token机制，我认为其本质思想就是将session中的信息简化不少，看成cookie用，也就是客户端的“session”。
好处
那Token机制相对于Cookie机制又有什么好处呢？
- 支持跨域访问: Cookie是不容许垮域访问的，这一点对Token机制是不存在的，前提 是传输的用户认证信息经过HTTP头传输.
- 无状态:Token机制本质是校验, 他获得的会话状态彻底来自于客户端, Token机制在服务端不须要存储session信息，由于 Token 自身包含了全部登陆用户的信息，只须要在客户端的cookie或本地介质存储状态信息.
- 更适用CDN: 能够经过内容分发网络请求你服务端的全部资料（如：javascript， HTML,图片等），而你的服务端只要提供API便可.
- 去耦: 不须要绑定到一个特定的身份验证方案。Token能够在任何地方生成，只要在 你的API被调用的时候，你能够进行Token生成调用便可.
- 更适用于移动应用: 当你的客户端是一个原平生台（iOS, Android，Windows 8等） 时，Cookie是不被支持的（你须要经过Cookie容器进行处理），这时采用Token认 证机制就会简单得多。 CSRF:由于再也不依赖于Cookie，因此你就不须要考虑对CSRF（跨站请求伪造）的防 范。
- 性能: 一次网络往返时间（经过数据库查询session信息）总比作一次HMACSHA256 计算 的Token验证和解析要费时得多. 不须要为登陆页面作特殊处理: 若是你使用Protractor 作功能测试的时候，再也不须要 为登陆页面作特殊处理.
- 基于标准化:你的API能够采用标准化的 JSON Web Token (JWT). 这个标准已经存在 多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）
缺陷在哪？
说了那么多token认证的好处，但他其实并无想象的那么神，token 也并非没有问题。
- 占带宽
正常状况下要比 session_id 更大，须要消耗更多流量，挤占更多带宽，假如你的网站每个月有 10 万次的浏览器，就意味着要多开销几十兆的流量。听起来并很少，但日积月累也是不小一笔开销。实际上，许多人会在 JWT 中存储的信息会更多。
- 不管如何你须要操做数据库
在网站上使用 JWT，对于用户加载的几乎全部页面，都须要从缓存/数据库中加载用户信息，若是对于高流量的服务，你肯定这个操做合适么？若是使用redis进行缓存，那么效率上也并不能比 session 更高效
- 没法在服务端注销，那么久很难解决劫持问题
- 性能问题
JWT 的卖点之一就是加密签名，因为这个特性，接收方得以验证 JWT 是否有效且被信任。可是大多数 Web 身份认证应用中，JWT 都会被存储到 Cookie 中，这就是说你有了两个层面的签名。听着彷佛很牛逼，可是没有任何优点，为此，你须要花费两倍的 CPU 开销来验证签名。对于有着严格性能要求的 Web 应用，这并不理想，尤为对于单线程环境。
JWT
如今咱们来讲说今天的主角，JWT
JSON Web Token（JWT）是一个很是轻巧的规范。这个规范容许咱们使用JWT在用 户和服务器之间传递安全可靠的信息
组成
一个JWT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。
头部(header)
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也能够 被表示成一个JSON对象。
{
"typ":"JWT",
"alg":"HS256"
}
这就是头部的明文内容，第一部分说明他是一个jwt，第二部分则指出签名算法用的是HS256算法。
而后将这个头部进行BASE64编码，编码后造成头部：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
载荷(payload)
载荷就是存放有效信息的地方,有效信息包含三个部分:
（1）标准中注册的声明（建议但不强制使用）
- iss: jwt签发者
- sub: jwt所面向的用户
- aud: 接收jwt的一方
- exp: jwt的过时时间，这个过时时间必需要大于签发时间
- nbf: 定义在什么时间以前，该jwt都是不可用的.
- iat: jwt的签发时间
- jti: jwt的惟一身份标识，主要用来做为一次性token,从而回避重放攻击。
（2）公共的声明
公共的声明能够添加任何的信息，通常添加用户的相关信息或其余业务须要的必要信息. 但不建议添加敏感信息，由于该部分在客户端可解密.
（3）私有的声明
私有声明是提供者和消费者所共同定义的声明，通常不建议存放敏感信息，由于base64 是对称解密的，意味着该部分信息能够归类为明文信息。
{
"sub":"1234567890",
"name":"tengshe789",
"admin": true
}
上面就是一个简单的载荷的明文，接下来使用base64加密：
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
签证（signature）
jwt的第三部分是一个签证信息，这个签证信息由三部分组成：
- header (base64后的)
- payload (base64后的)
- secret
这个部分须要base64加密后的header和base64加密后的payload使用.链接组成的字符串，而后经过header中声明的加密方式进行加盐secret组合加密，而后就构成了jwt的第 三部分。
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
合成
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6I kpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7Hg Q
实现JWT
如今通常实现jwt，都使用Apache 的开源项目JJWT（一个提供端到端的JWT建立和验证的Java库）。
依赖
<!-- https://mvnrepository.com/artifact/io.jsonwebtoken/jjwt -->
<dependency>
<groupId>io.jsonwebtoken</groupId>
<artifactId>jjwt</artifactId>
<version>0.7.0</version>
</dependency>
建立token的demo
public class CreateJWT {
public static void main(String[] args) throws Exception{
JwtBuilder builder = Jwts.builder().setId("123")
.setSubject("jwt所面向的用户")
.setIssuedAt(new Date())
.signWith(SignatureAlgorithm.HS256,"tengshe789");
String s = builder.compact();
System.out.println(s);
//eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxMjMiLCJzdWIiOiJqd3TmiYDpnaLlkJHnmoTnlKjmiLciLCJpYXQiOjE1NDM3NTk0MjJ9.1sIlEynqqZmA4PbKI6GgiP3ljk_aiypcsUxSN6-ATIA
}
}
结果如图：
（注意，jjwt不支持jdk11，0.9.1之后的jjwt必须实现signWith()方法才能实现）
解析Token的demo
public class ParseJWT {
public static void main(String[] args) {
String token = "eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIxMjMiLCJzdWIiOiJqd3TmiYDpnaLlkJHnmoTnlKjmiLciLCJpYXQiOjE1NDM3NTk0MjJ9.1sIlEynqqZmA4PbKI6GgiP3ljk_aiypcsUxSN6-ATIA";
Claims claims =
Jwts.parser().setSigningKey("tengshe789").parseClaimsJws(token).getBody();
System.out.println("id"+claims.getId());
System.out.println("Subject"+claims.getSubject());
System.out.println("IssuedAt"+claims.getIssuedAt());
}
}
结果如图：
生产中的JWT
在企业级系统中，一般内部会有很是多的工具平台供你们使用，好比人力资源，代码管理，日志监控，预算申请等等。若是每个平台都实现本身的用户体系的话无疑是巨大的浪费，因此公司内部会有一套公用的用户体系，用户只要登录以后，就可以访问全部的系统。
这就是 单点登陆（SSO: Single Sign-On）
SSO 是一类解决方案的统称，而在具体的实施方面，通常有两种策略可供选择：
- SAML 2.0
- OAuth 2.0
欲扬先抑，先说说几个重要的知识点。
Authentication VS Authorisation
- Authentication: 身份鉴别，鉴权，如下简称认证
认证 的做用在于承认你有权限访问系统，用于鉴别访问者是不是合法用户。负责认证的服务一般称为 Authorization Server 或者 Identity Provider，如下简称 IdP
- Authorisation: 受权
受权 用于决定你有访问哪些资源的权限。大多数人不会区分这二者的区别，由于站在用户的立场上。而做为系统的设计者来讲，这二者是有差异的，这是不一样的两个工做职责，咱们能够只须要认证功能，而不须要受权功能，甚至不须要本身实现认证功能，而借助 Google 的认证系统，即用户能够用 Google 的帐号进行登录。负责提供资源（API调用）的服务称为 Resource Server 或者 Service Provider，如下简称 SP
SMAL 2.0
OAuth（JWT）
OAuth（开放受权）是一个开放的受权标准，容许用户让第三方应用访问该用户在 某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
流程能够参考以下：
简单的来讲，就是你要访问一个应用服务，先找它要一个request token（请求令牌），再把这个request token发到第三方认证服务器，此时第三方认证服务器会给你一个aceess token（通行令牌）, 有了aceess token你就可使用你的应用服务了。
注意图中第4步兑换 access token 的过程当中，不少第三方系统，如Google ，并不会仅仅返回 access token，还会返回额外的信息，这其中和以后更新相关的就是 refresh token。一旦 access token 过时，你就能够经过 refresh token 再次请求 access token。
固然了，流程是根据你的请求方式和访问的资源类型而定的，业务不少也是不同的，我这是简单的聊聊。
如今这种方法比较常见，常见的譬如使用QQ快速登录，用的基本的都是这种方法。
开源项目
咱们用一个很火的开源项目Cloud-Admin为栗子，来分析一下jwt的应用。
Cloud-Admin是基于Spring Cloud微服务化开发平台，具备统一受权、认证后台管理系统，其中包含具有用户管理、资源权限管理、网关API管理等多个模块，支持多业务系统并行开发。
目录结构
鉴权中心功能在ace-auth与ace-gate下。
模型
下面是官方提供的架构模型。
能够看到，AuthServer在架构的中心环节，要访问服务，必须须要鉴权中心的JWT鉴权。
鉴权中心服务端代码解读
实体类
先看实体类，这里鉴权中心定义了一组客户端实体，以下：
@Table(name = "auth_client")
@Getter
@Setter
public class Client {
@Id
private Integer id;
private String code;
private String secret;
private String name;
private String locked = "0";
private String description;
@Column(name = "crt_time")
private Date crtTime;
@Column(name = "crt_user")
private String crtUser;
@Column(name = "crt_name")
private String crtName;
@Column(name = "crt_host")
private String crtHost;
@Column(name = "upd_time")
private Date updTime;
@Column(name = "upd_user")
private String updUser;
@Column(name = "upd_name")
private String updName;
@Column(name = "upd_host")
private String updHost;
private String attr1;
private String attr2;
private String attr3;
private String attr4;
private String attr5;
private String attr6;
private String attr7;
private String attr8;
对应数据库：
CREATE TABLE `auth_client` ( `id` int(11) NOT NULL AUTO_INCREMENT, `code` varchar(255) DEFAULT NULL COMMENT '服务编码', `secret` varchar(255) DEFAULT NULL COMMENT '服务密钥', `name` varchar(255) DEFAULT NULL COMMENT '服务名', `locked` char(1) DEFAULT NULL COMMENT '是否锁定', `description` varchar(255) DEFAULT NULL COMMENT '描述', `crt_time` datetime DEFAULT NULL COMMENT '建立时间', `crt_user` varchar(255) DEFAULT NULL COMMENT '建立人', `crt_name` varchar(255) DEFAULT NULL COMMENT '建立人姓名', `crt_host` varchar(255) DEFAULT NULL COMMENT '建立主机', `upd_time` datetime DEFAULT NULL COMMENT '更新时间', `upd_user` varchar(255) DEFAULT NULL COMMENT '更新人', `upd_name` varchar(255) DEFAULT NULL COMMENT '更新姓名', `upd_host` varchar(255) DEFAULT NULL COMMENT '更新主机', `attr1` varchar(255) DEFAULT NULL, `attr2` varchar(255) DEFAULT NULL, `attr3` varchar(255) DEFAULT NULL, `attr4` varchar(255) DEFAULT NULL, `attr5` varchar(255) DEFAULT NULL, `attr6` varchar(255) DEFAULT NULL, `attr7` varchar(255) DEFAULT NULL, `attr8` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8mb4;
这些是每组微服务客户端的信息
第二个实体类，就是客户端_服务的实体，也就是对应着那些微服务客户端能调用哪些微服务客户端：
大概对应的就是微服务间调用权限关系。
@Table(name = "auth_client_service")
public class ClientService {
@Id
private Integer id;
@Column(name = "service_id")
private String serviceId;
@Column(name = "client_id")
private String clientId;
private String description;
@Column(name = "crt_time")
private Date crtTime;
@Column(name = "crt_user")
private String crtUser;
@Column(name = "crt_name")
private String crtName;
@Column(name = "crt_host")
private String crtHost;}
接口层
咱们跳着看，先看接口层
@RestController
@RequestMapping("jwt")
@Slf4j
public class AuthController {
@Value("${jwt.token-header}")
private String tokenHeader;
@Autowired
private AuthService authService;
@RequestMapping(value = "token", method = RequestMethod.POST)
public ObjectRestResponse<String> createAuthenticationToken(
@RequestBody JwtAuthenticationRequest authenticationRequest) throws Exception {
log.info(authenticationRequest.getUsername()+" require logging...");
final String token = authService.login(authenticationRequest);
return new ObjectRestResponse<>().data(token);
}
@RequestMapping(value = "refresh", method = RequestMethod.GET)
public ObjectRestResponse<String> refreshAndGetAuthenticationToken(
HttpServletRequest request) throws Exception {
String token = request.getHeader(tokenHeader);
String refreshedToken = authService.refresh(token);
return new ObjectRestResponse<>().data(refreshedToken);
}
@RequestMapping(value = "verify", method = RequestMethod.GET)
public ObjectRestResponse<?> verify(String token) throws Exception {
authService.validate(token);
return new ObjectRestResponse<>();
}
}
这里放出了三个接口
先说第一个接口，建立token。
具体逻辑以下：
每个用户登录进来时，都会进入这个环节。根据request中用户的用户名和密码，利用feign客户端的拦截器拦截request，而后使用做者写的JwtTokenUtil里面的各类方法取出token中的key和密钥，验证token是否正确，正确则用authService.login(authenticationRequest);的方法返回出去一个新的token。
public String login(JwtAuthenticationRequest authenticationRequest) throws Exception {
UserInfo info = userService.validate(authenticationRequest);
if (!StringUtils.isEmpty(info.getId())) {
return jwtTokenUtil.generateToken(new JWTInfo(info.getUsername(), info.getId() + "", info.getName()));
}
throw new UserInvalidException("用户不存在或帐户密码错误!");
}
下图是详细逻辑图：
鉴权中心客户端代码
入口
做者写了个注解的入口，使用@EnableAceAuthClient即自动开启微服务(客户端)的鉴权管理
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(AutoConfiguration.class)
@Documented
@Inherited
public @interface EnableAceAuthClient {
}
配置
接着沿着注解的入口看
@Configuration
@ComponentScan({"com.github.wxiaoqi.security.auth.client","com.github.wxiaoqi.security.auth.common.event"})
public class AutoConfiguration {
@Bean
ServiceAuthConfig getServiceAuthConfig(){
return new ServiceAuthConfig();
}
@Bean
UserAuthConfig getUserAuthConfig(){
return new UserAuthConfig();
}
}
注解会自动的将客户端的用户token和服务token的关键信息加载到bean中
feigin拦截器
做者重写了okhttp3拦截器的方法，每一次微服务客户端请求的token都会被拦截下来，验证服务调用服务的token和用户调用服务的token是否过时，过时则返回新的token
@Override
public Response intercept(Chain chain) throws IOException {
Request newRequest = null;
if (chain.request().url().toString().contains("client/token")) {
newRequest = chain.request()
.newBuilder()
.header(userAuthConfig.getTokenHeader(), BaseContextHandler.getToken())
.build();
} else {
newRequest = chain.request()
.newBuilder()
.header(userAuthConfig.getTokenHeader(), BaseContextHandler.getToken())
.header(serviceAuthConfig.getTokenHeader(), serviceAuthUtil.getClientToken())
.build();
}
Response response = chain.proceed(newRequest);
if (HttpStatus.FORBIDDEN.value() == response.code()) {
if (response.body().string().contains(String.valueOf(CommonConstants.EX_CLIENT_INVALID_CODE))) {
log.info("Client Token Expire,Retry to request...");
serviceAuthUtil.refreshClientToken();
newRequest = chain.request()
.newBuilder()
.header(userAuthConfig.getTokenHeader(), BaseContextHandler.getToken())
.header(serviceAuthConfig.getTokenHeader(), serviceAuthUtil.getClientToken())
.build();
response = chain.proceed(newRequest);
}
}
return response;
}
spring容器的拦截器
第二道拦截器是来自spring容器的，第一道feign拦截器只是验证了两个token是否过时，但token真实的权限却没验证。接下来就要验证两个token的权限问题了。
服务调用权限代码以下：
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HandlerMethod handlerMethod = (HandlerMethod) handler;
// 配置该注解，说明不进行服务拦截
IgnoreClientToken annotation = handlerMethod.getBeanType().getAnnotation(IgnoreClientToken.class);
if (annotation == null) {
annotation = handlerMethod.getMethodAnnotation(IgnoreClientToken.class);
}
if(annotation!=null) {
return super.preHandle(request, response, handler);
}
String token = request.getHeader(serviceAuthConfig.getTokenHeader());
IJWTInfo infoFromToken = serviceAuthUtil.getInfoFromToken(token);
String uniqueName = infoFromToken.getUniqueName();
for(String client:serviceAuthUtil.getAllowedClient()){
if(client.equals(uniqueName)){
return super.preHandle(request, response, handler);
}
}
throw new ClientForbiddenException("Client is Forbidden!");
}
用户权限：
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HandlerMethod handlerMethod = (HandlerMethod) handler;
// 配置该注解，说明不进行用户拦截
IgnoreUserToken annotation = handlerMethod.getBeanType().getAnnotation(IgnoreUserToken.class);
if (annotation == null) {
annotation = handlerMethod.getMethodAnnotation(IgnoreUserToken.class);
}
if (annotation != null) {
return super.preHandle(request, response, handler);
}
String token = request.getHeader(userAuthConfig.getTokenHeader());
if (StringUtils.isEmpty(token)) {
if (request.getCookies() != null) {
for (Cookie cookie : request.getCookies()) {
if (cookie.getName().equals(userAuthConfig.getTokenHeader())) {
token = cookie.getValue();
}
}
}
}
IJWTInfo infoFromToken = userAuthUtil.getInfoFromToken(token);
BaseContextHandler.setUsername(infoFromToken.getUniqueName());
BaseContextHandler.setName(infoFromToken.getName());
BaseContextHandler.setUserID(infoFromToken.getId());
return super.preHandle(request, response, handler);
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
BaseContextHandler.remove();
super.afterCompletion(request, response, handler, ex);
}
spring cloud gateway网关代码
该框架中全部的请求都会走网关服务（ace-gatev2），经过网关，来验证token是否过时异常，验证token是否不存在，验证token是否有权限进行服务。
下面是核心代码：
@Override
public Mono<Void> filter(ServerWebExchange serverWebExchange, GatewayFilterChain gatewayFilterChain) {
log.info("check token and user permission....");
LinkedHashSet requiredAttribute = serverWebExchange.getRequiredAttribute(ServerWebExchangeUtils.GATEWAY_ORIGINAL_REQUEST_URL_ATTR);
ServerHttpRequest request = serverWebExchange.getRequest();
String requestUri = request.getPath().pathWithinApplication().value();
if (requiredAttribute != null) {
Iterator<URI> iterator = requiredAttribute.iterator();
while (iterator.hasNext()){
URI next = iterator.next();
if(next.getPath().startsWith(GATE_WAY_PREFIX)){
requestUri = next.getPath().substring(GATE_WAY_PREFIX.length());
}
}
}
final String method = request.getMethod().toString();
BaseContextHandler.setToken(null);
ServerHttpRequest.Builder mutate = request.mutate();
// 不进行拦截的地址
if (isStartWith(requestUri)) {
ServerHttpRequest build = mutate.build();
return gatewayFilterChain.filter(serverWebExchange.mutate().request(build).build());
}
IJWTInfo user = null;
try {
user = getJWTUser(request, mutate);
} catch (Exception e) {
log.error("用户Token过时异常", e);
return getVoidMono(serverWebExchange, new TokenForbiddenResponse("User Token Forbidden or Expired!"));
}
List<PermissionInfo> permissionIfs = userService.getAllPermissionInfo();
// 判断资源是否启用权限约束
Stream<PermissionInfo> stream = getPermissionIfs(requestUri, method, permissionIfs);
List<PermissionInfo> result = stream.collect(Collectors.toList());
PermissionInfo[] permissions = result.toArray(new PermissionInfo[]{});
if (permissions.length > 0) {
if (checkUserPermission(permissions, serverWebExchange, user)) {
return getVoidMono(serverWebExchange, new TokenForbiddenResponse("User Forbidden!Does not has Permission!"));
}
}
// 申请客户端密钥头
mutate.header(serviceAuthConfig.getTokenHeader(), serviceAuthUtil.getClientToken());
ServerHttpRequest build = mutate.build();
return gatewayFilterChain.filter(serverWebExchange.mutate().request(build).build());
}
cloud admin总结
总的来讲，鉴权和网关模块就说完了。做者代码构思极其精妙，使用在大型的权限系统中，能够巧妙的减小耦合性，让服务鉴权粒度细化，方便管理。
结束
此片完了~ 想要了解更多精彩新姿式？
请访问个人我的博客
本篇为原创内容，已在我的博客率先发表，随后看心情可能会在CSDN，segmentfault，掘金，简书，开源中国同步发出。若有雷同，缘分呢兄弟。赶快加个好友，我们两个想个号码， 买个彩票，先挣他个几百万😝
- 1. 分布式系统--感性认识JWT
- 2. 感性认识JWT
- 3. 认识HDFS分布式文件系统
- 4. 认识分布式（分布式笔记）
- 5. 分布式系统缓存系列一 认识缓存
- 6. 分布式声波传感系统DAS
- 7. 分布式系统的高可用性_分布式系统中的可用性
- 8. 认识JWT
- 9. 认识JWT(转)
- 10. 分布式系统认证方案
- 更多相关文章...
- • 操作系统（OS）平台 统计 - 浏览器信息
- • 系统定义的TypeHandler - MyBatis教程
- • 再有人问你分布式事务，把这篇扔给他
- • 常用的分布式事务解决方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 分布式系统--感性认识JWT
- 2. 感性认识JWT
- 3. 认识HDFS分布式文件系统
- 4. 认识分布式（分布式笔记）
- 5. 分布式系统缓存系列一 认识缓存
- 6. 分布式声波传感系统DAS
- 7. 分布式系统的高可用性_分布式系统中的可用性
- 8. 认识JWT
- 9. 认识JWT(转)
- 10. 分布式系统认证方案