说明
开发公司昨天我发了一个版本的验证博客,开发公司到今天早上我再研究了一下,开发公司发现了一些问题:
- 开发公司昨天那个单点登录是在开发公司每个模块的基础上做的,开发公司也就是说如果你想让每开发公司个模块都如认证中心认证,开发公司就要在每个模块里进行相关配置,开发公司这还不是最紧要的,你要想想,开发公司因为我们是通过注解的开发公司方式在对应的方法鉴权,开发公司这样的话就会导致我们开发公司每次访问这个方法的时开发公司候就要去认证中心请求一次,开发公司也就是鉴权一次,开发公司那么整个系统模块又多,路径又多,开发公司认证中心肯定是吃不消的啊.
- 开发公司所以在这个基础上,开发公司就需要去将认证中心在开发公司第一次认证产生的token,交给前端,然后在GateWay开发公司里进行一个token的验证,开发公司这样子就避免我们每一开发公司次都要去认证中心里认证了,效率很高.
所以,开发公司下面就是介绍与GateWay开发公司结合的方式去认证.
基于SpringSecurity+GateWay
认证中心
开发公司这里我为什么没提OAuth,因为没有OAuth开发公司也是可以进行鉴权的,开发公司但是这种方式你必须使开发公司用一个中间件,开发公司去保存需要鉴权的路径,开发公司哪些角色可以访问哪些开发公司路径你必须保存下来,开发公司因为我们在单个微服务开发公司上是没有鉴权操作了的,而是在GateWay里鉴权,开发公司所以无法在每个方法上开发公司加上注解的方式去鉴权,开发公司就必须得保存每个路径开发公司是哪个角色可以访问的.
开发公司所以这里就必须由一个开发公司基本的关系,开发公司做这个之前必须得清楚:
一个用户可以由多个角色,一个角色又可以有多个权限,所以这个用户包含其所拥有角色的所有权限.
怎么给用户赋予角色,给角色赋予权限,是数据库的事情了,假如这里已经有一些数据,反正你就记得是这个结构就行.
那么下面的鉴权流程可以是
前端有一个请求,直接打到了认证中心,这个时候,先来到AbstractAuthenticationProcessingFilter中的doFilter方法进行请求过滤,通常可以实现自定义过滤器,过滤成功,尝试鉴权attemptAuthentication,这个方法是由其子类UsernamePasswordAuthenticationFilter实现的,通常可以实现自定义鉴权,然后来到UserDetailsService的loadUserByUsername方法,这个方法经常用来做自定义登录逻辑,授权成功后执行successfulAuthentication方法,这个方法在doFilter方法里被调用,底层会调用核心方法onAuthenticationSuccess,该方法用来实现自定义授权成功逻辑,相反,就有一个自定义授权失败逻辑AuthenticationFailureHandler接口中的onAuthenticationFailure方法
这里多提一嘴,如果是要自定义鉴权逻辑去代替系统的逻辑,一般都是通过自定义才能实现多彩的鉴权方案,至于有些人为什么自定义鉴权逻辑没有生效,那是因为你没有在配置方法configure(HttpSecurity http)中加入这些个逻辑.
下面开始上代码了,先直接上代码,继续往下我会给出相关代码的解释
- 我没有实现自定义过滤器和鉴权器,还是用原来的,而是直接从自定义登录逻辑开始:
@Componentpublic class SheepUserDetailsService implements UserDetailsService { @Autowired private PasswordEncoder passwordEncoder; @Override public UserDetails loadUserByUsername(String s) throws UsernameNotFoundException { System.out.println("函数进来了"); if( !"admin".equals(s) ) throw new UsernameNotFoundException("用户" + s + "不存在" ); //TODO //根据用户名查询对应角色,然后根据角色查询对应所能访问路径 //将这些路径包装成集合传过去 //获取你直接查询到了角色,先将角色传过去,我这里是先将角色传过去 int id=0; return new User( s+"-"+id, passwordEncoder.encode("123456"), AuthorityUtils.commaSeparatedStringToAuthorityList("ROLE_NORMAL,ROLE_MEDIUM")); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 这个时候就会鉴权,然后调用成功处理的方法:
@Override public void onAuthenticationSuccess(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Authentication authentication) throws IOException, ServletException { User principal = (User) authentication.getPrincipal(); String username = principal.getUsername(); String[] users = username.split("-"); // TODO 得到该用户全部角色 //Collection<GrantedAuthority> authorities = principal.getAuthorities(); //TODO 查询数据库得到该角色所能访问的全部路径 //模拟: String[] s1=new String[]{"/login","/register","/serviceedu/front/listTeacher"}; //将权限路径封装到redis中 redisUtils.setCollectionSet(users[0],s1,24, TimeUnit.HOURS); String s= redisUtils.get("fromUrl"); if (s==null) s="/"; String jwtToken = JwtUtils.getJwtToken(users[1], users[0]); Msg msg = Msg.success().data("username", users[0]).data("fromUrl",s).data("token",jwtToken); redisUtils.del("fromUrl"); httpServletResponse.setContentType("text/json;charset=utf-8"); //塞到HttpServletResponse中返回给前台 httpServletResponse.getWriter().write(JSON.toJSONString(msg)); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 这里也给出授权失败的自定义逻辑:
@Componentpublic class FailHandler implements AuthenticationFailureHandler { @Override public void onAuthenticationFailure(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, AuthenticationException e) throws IOException, ServletException { Msg fail = Msg.fail().data("message", "登录失败或权限不足"); httpServletResponse.setContentType("text/json;charset=utf-8"); //塞到HttpServletResponse中返回给前台 //这种方式很常用,后面的代码都有很多,唯一能反馈给前端json格式的消息 httpServletResponse.getWriter().write(JSON.toJSONString(fail)); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 这里也给出自定义登录的逻辑,这个逻辑很简单,就是将cookie删除就可以了,token可以删除也可以不删除
@Componentpublic class CustomLogoutSuccessHandler extends AbstractAuthenticationTargetUrlRequestHandler implements LogoutSuccessHandler { @Override public void onLogoutSuccess(HttpServletRequest request, HttpServletResponse response, Authentication authentication) throws IOException, ServletException { // 将子系统的cookie删掉 //建议将token也删除,直接写个controller接口就可以了,可以在前端调用/logout的同时调用删除token接口 Cookie[] cookies = request.getCookies(); if(cookies != null && cookies.length>0){ for (Cookie cookie : cookies){ cookie.setMaxAge(0); cookie.setPath("/"); response.addCookie(cookie); } } super.handle(request, response, authentication); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 那么最关键的一步来了,记得将这些自定义登录逻辑代码加上配置中:
@Configurationpublic class SpringSecurityConfig extends WebSecurityConfigurerAdapter { @Autowired private UserDetailsService userDetailsService; @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } @Autowired SuccessHandler successHandler; @Autowired FailHandler failHandler; @Autowired private CustomLogoutSuccessHandler customLogoutSuccessHandler; //@Autowired //CustomizeAuthenticationEntryPoint customizeAuthenticationEntryPoint;// @Autowired// MyUsernamePasswordAuthenticationFilter myUsernamePasswordAuthenticationFilter; @Bean public DaoAuthenticationProvider authenticationProvider() { DaoAuthenticationProvider authenticationProvider = new DaoAuthenticationProvider(); authenticationProvider.setUserDetailsService(userDetailsService); authenticationProvider.setPasswordEncoder(passwordEncoder()); authenticationProvider.setHideUserNotFoundExceptions(false); return authenticationProvider; } @Override protected void configure(HttpSecurity http) throws Exception { http.formLogin()// .usernameParameter("mobile")// .passwordParameter("password") //自定义登录页面,这个页面是一个controller路径 //我们只需要在对应的controller中重定向到你前端的页面就可以了 .loginPage("/unLogin") //登录处理逻辑路径,/login代表用系统的处理逻辑 //但是我们重写了用户逻辑,所以会走到重写的用户逻辑里 .loginProcessingUrl("/login") //自定义鉴权成功处理 .successHandler(successHandler) //自定义鉴权失败处理 .failureHandler(failHandler) .permitAll() .and() .logout() //自定义登录成功处理 .logoutSuccessHandler(customLogoutSuccessHandler) // 无效会话 .invalidateHttpSession(true) // 清除身份验证 .clearAuthentication(true) .and().csrf().disable(); //异常处理(权限拒绝、登录失效等)// .exceptionHandling()// .authenticationEntryPoint(customizeAuthenticationEntryPoint); http.authorizeRequests() .antMatchers( "/oauth/**", "/login/**", "/unLogin", "/logout/**", "/uac/oauth/token", "http://localhost:3000/login", "http://localhost:8085/uac/login" ).permitAll().anyRequest().authenticated();//将@bean注入的鉴权器加入到配置当中 //http.addFilterAt(myAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); }//如果自定义鉴权器,也要做相关配置,不然不走你的鉴权器// @Bean// MyUsernamePasswordAuthenticationFilter myAuthenticationFilter() throws Exception {// MyUsernamePasswordAuthenticationFilter filter = new MyUsernamePasswordAuthenticationFilter();// filter.setAuthenticationManager(authenticationManagerBean());// filter.setAuthenticationSuccessHandler(successHandler);// filter.setAuthenticationFailureHandler(failHandler);// return filter;// } @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.authenticationProvider(authenticationProvider()); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
认证中心这样的就完成了,有人会问,怎么没有OAtuh的配置?注意我这里是用SpringSecurity+GateWay方式去认证,用不到OAuth.
这也是为什么你会看到我用了一个redis去保存用户跟权限这两者的关系,我这里为什么不保存角色,因为没那个必要,虽然一个用户有多个角色,但是这些角色下的权限都属于用户的,而前端传过来的是路径,所以这里我们只是存储用户跟路径权限之间的关系,到时候就可以直接判断该用户是否可以访问该路径了.
那么还有一个小问题就是,你会发现我并没有利用认证中心底层给我生成的token,这个token很难利用上,要利用的话估计要实现自定义过滤器,反正我拿不到.
但是我想到了一个绝妙且笨的方法,就是在鉴权成功的自定义处理方法中,可以直接用RestTemplate发送一个/oauth/token的请求,这样子不就直接拿到token值了吗?然后将其反馈给前端,也不用我们自己去生成这个token
GateWay网关层面
- GateWay网关这个层面,因为我们用redis保存了权限和用户的映射表,所以只要在全局过滤器里判断就可以了.
- 第一次我们token为空,说明没有登录,这个时候就需要提醒用户去登录页面进行登录了,登录成功后,认证中心反馈一个url给前端,让前端去跳转对应的路径,这个路径一般是我们在进入登录页面前的页面.注意,如果你使用了前端某个页面作为登录页面,一定要在认证中心里的loginPage方法指定前端登录页面,不然你前端的登录是无效的,这个时候你前端的登录表单提交按钮,可以直接请求到认证中心的/login路径,然后认证中心才会承认你前端登录页面提交的数据有效
这下子前面就达到了前后端分离的效果. - 前面是token为空的情况,如果token不为空,我们为了提升效率,就不能放行让每个微服务单独的鉴权,而是在网关层面鉴权,这里的鉴权很简单,直接用前端传来的token去验证其合法性,合法了就解析其用户名,然后将用户名去redis去查询对应的权限.
@Component("a")@Order(2) //设置执行优先级，在 全局权限认证过滤器 之前执行public class AuthenticationFilter implements GlobalFilter, InitializingBean { @Autowired private RestTemplate restTemplate; @Autowired RedisUtils redisUtils; private static Set<String> shouldSkipUrl = new LinkedHashSet<>(); @Override public void afterPropertiesSet() throws Exception { // 在类被初始化完成时，把不拦截认证的请求放入集合 shouldSkipUrl.add("/uac"); shouldSkipUrl.add("/serviceedu/front/listTeacher"); } @SneakyThrows @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { //获取request请求 String requestPath = exchange.getRequest().getURI().getPath(); //如果请求url不需要认证，直接跳过 if(shouldSkip(requestPath)) { return chain.filter(exchange); } //获取Authorization请求头 String token = exchange.getRequest().getHeaders().getFirst("token"); //Authorization请求头为空，抛异常 if(StringUtils.isEmpty(token)) { return out(exchange.getResponse()); } redisUtils.set("fromUrl",requestPath,10, TimeUnit.MINUTES); if (!JwtUtils.checkToken(token)){ return out(exchange.getResponse()); } Claims memberClaims = JwtUtils.getMemberClaims(token); if (memberClaims==null) return out(exchange.getResponse()); String nickname = (String) memberClaims.get("nickname"); Set<String> set = redisUtils.getSet(nickname); if (!hasPermisson(set,requestPath)){ exchange.getResponse().setStatusCode(HttpStatus.NON_AUTHORITATIVE_INFORMATION); return exchange.getResponse().setComplete(); } return chain.filter(exchange); } private Mono<Void> out(ServerHttpResponse response) { JsonObject message = new JsonObject(); message.addProperty("success", false); message.addProperty("code", 20001); message.addProperty("data", "鉴权失败"); byte[] bits = message.toString().getBytes(StandardCharsets.UTF_8); DataBuffer buffer = response.bufferFactory().wrap(bits); //response.setStatusCode(HttpStatus.UNAUTHORIZED); //指定编码，否则在浏览器中会中文乱码 response.getHeaders().add("Content-Type", "application/json;charset=UTF-8"); return response.writeWith(Mono.just(buffer)); } private boolean hasPermisson(Set<String> set,String path){ for (String s : set) { if (path.contains(s)) return true; } return false; } private boolean shouldSkip(String reqPath) { for(String skipPath:shouldSkipUrl) { if(reqPath.contains(skipPath)) { return true; } } return false; }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
这样子,验证失败了,我们也能传给前端一个json格式的数据,让前端做出反应,验证成功后,就可以放心大胆的去让用户浏览该路径了,效率很高,因为只有第一次需要请求认证中心鉴权,往后直接拿token解析取出redis中的映射路径去鉴权.
其实这里我有个问题的: 就是如果在GateWay网关鉴权,那有用户绕过了网关去访问某个微服务呢?这又该怎么办,那岂不是所有的权限都暴露出来,但是我又想到了其实绕过去极为困难.
- 先不说有专门的安全人员去维护
- 其次是只有在网关做了跨越处理,而其他微服务是没有跨域的,所以理论上是访问不了了,请求必须经过网关.
但我们不得不承认的事情是,凡事都有两面性,你在网关鉴权了,效率上是高,但是加重了网关的负担,提高了单点故障的风险,如果网关挂了怎么办?通常只能搞成网关"集群"了.
SpringSecurity+GateWay+OAtuh2
这个其实可以省去redis,就是利用RestTemplate来进行鉴权,也是在网关处,加快性能:
@Component("a")@Order(2) //设置执行优先级，在 全局权限认证过滤器 之前执行public class AuthenticationFilter implements GlobalFilter, InitializingBean { @Autowired private RestTemplate restTemplate; @Autowired RedisUtils redisUtils; private static Set<String> shouldSkipUrl = new LinkedHashSet<>(); @Override public void afterPropertiesSet() throws Exception { // 在类被初始化完成时，把不拦截认证的请求放入集合 shouldSkipUrl.add("/uac"); shouldSkipUrl.add("/serviceedu/front/listTeacher"); } @SneakyThrows @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { //获取request请求 String requestPath = exchange.getRequest().getURI().getPath(); //如果请求url不需要认证，直接跳过 if(shouldSkip(requestPath)) { return chain.filter(exchange); } //获取Authorization请求头 String token = exchange.getRequest().getHeaders().getFirst("token"); //Authorization请求头为空，抛异常 if(StringUtils.isEmpty(token)) { return out(exchange.getResponse()); } TokenInfo tokenInfo=null; try { //往授权服务发http请求 /oauth/check_token 并封装返回结果！ tokenInfo = getTokenInfo(authHeader); }catch (Exception e) { throw new RuntimeException("校验令牌异常"); } if(!hasPremisson(tokenInfor,requestPath){ return out(exchange.getResponse()); } return chain.filter(exchange); } private Mono<Void> out(ServerHttpResponse response) { JsonObject message = new JsonObject(); message.addProperty("success", false); message.addProperty("code", 20001); message.addProperty("data", "鉴权失败"); byte[] bits = message.toString().getBytes(StandardCharsets.UTF_8); DataBuffer buffer = response.bufferFactory().wrap(bits); //response.setStatusCode(HttpStatus.UNAUTHORIZED); //指定编码，否则在浏览器中会中文乱码 response.getHeaders().add("Content-Type", "application/json;charset=UTF-8"); return response.writeWith(Mono.just(buffer)); } private boolean hasPremisson(TokenInfo tokenInfo,String currentUrl) { boolean hasPremisson = false; //登录用户所拥有的请求url权限集合 List<String> premessionList = Arrays.asList(tokenInfo.getAuthorities()); //与当前请求url，看是否有对应的访问权限 for (String url: premessionList) { if(currentUrl.contains(url)) { hasPremisson = true; break; } } //如果没有，抛异常 if(!hasPremisson){ throw new RuntimeException("没有权限"); } return hasPremisson; } private boolean shouldSkip(String reqPath) { for(String skipPath:shouldSkipUrl) { if(reqPath.contains(skipPath)) { return true; } } return false; } private TokenInfo getTokenInfo(String authHeader) { // 往授权服务发请求 /oauth/check_token // 获取token的值 String token = StringUtils.substringAfter(authHeader, "bearer "); //组装请求头 HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED); //必须设置 basicAuth为对应的 clienId、 clientSecret headers.setBasicAuth("admin", "123456"); MultiValueMap<String, String> params = new LinkedMultiValueMap<>(); params.add("token", token); HttpEntity<MultiValueMap<String, String>> entity = new HttpEntity<>(params, headers); //往授权服务发http请求 /oauth/check_token ResponseEntity<TokenInfo> response = restTemplate.exchange("http://localhost:8085/uac/oauth/check_token", HttpMethod.POST, entity, TokenInfo.class); //获取响应结果 TokenInfo return response.getBody(); }}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
网上的鉴权方式差不多都是这个方式,直接发送RestTemplate风格的请求去验证token是否正确,然后返回一个权限列表,但在这里需要注意的一点是:
你这个token必须从前端过来是认证中心生成的那个,因为你要发送check_token请求是去认证中心底层/oauth/check_token路径验证的,那它肯定是拿自己生成那个token验证,而且你必须将这个token反馈给前端,就需要知道如何在认证中心的认证成功方法里将底层的token反馈给前端,这样这边网关层才能发送过来,如果你需要验证自己生成的token,可以在认证中心自定义/oauth/token,所以这个方法很麻烦.
其实这里我提出一个疑惑,我在网上看的时候,有人用这种方法重写了两个全局过滤器,有些蒙蔽,为啥要这样做,不是多余了吗?他是将两个一样的过滤器分不同前后加载到ioc容器中,然后在前一个过滤器采用setAttribute的方式放在里面,之后在后面的过滤器里取出来,???各位网友可以说说,是不是多余了,用了两个一模一样的过滤器,直接在第一个过滤器里查出来后验证不就行了吗?
上面的GateWay网关中,还可以这样优化:
因为你从验证中心发送请求获取数据的,所以你必须得每次都请求一次,这样子效率不太好,所以你可以将第一次请求的数据缓存下来,网上的方式都是放在请求头里,一般不要这样做,因为请求头我完全可以在前端制造,这样子就危险了,而是放在redis里,在请求之前先查缓存,如果没有缓存再请求,有缓存就直接拿出缓存鉴权.这样子是不是发现又回到了第一个方式的鉴权?所以我没有使用第二种方式.
注意点
- 使用第一种方式的时候,可以不加上OAtuh2的配置,加上了也不起效果,但是第二种就必须得加上了OAuth2这个配置了,因为你要请求/oauth/checkt_token,想要配置的可以直接去我昨天的博文里看看,链接放在开头了.
- 有些简单的代码我是没有加上去的,你要认真看完,不然复制代码是肯定不行的.
- 我的认证中心代码地址: