springsecurity登录（Spring Security处理登出（Logout））

本文目录

• Spring Security处理登出(Logout)
• Spring Security 使用非spring默认的登陆页面，是如何跳转到登陆成功页面的
• springboot 整合springsecurity 前后端分离怎么实现登陆
• SpringSecurity登录原理（源码级讲解）
• 2021-04-06 SpringSecurity登录 跨域JSESSIONID失效

Spring Security处理登出(Logout)

Spring Security内置的东西很多，有时候比较方便，但有时候因不了解其内部机制很可能出现一些问题。这里说下Spring Security对登出的支持。

Security默认的登出地址为： /logout ，在登出后会进行如下操作：

当然除了默认的操作，开发者更希望能自己灵活配置。

LogoutHandler 即在程序执行logout时一起参与执行其中的处理逻辑， 不能抛出异常 ，官方默认提供了几个实现。

在调用完LogoutHandler之后，并且处理成功后调用， 可以抛出异常 ，官方默认提供了两个

在登出的时候区分是 接口登出 还是 页面登出 ，针对不同的登出做不同的处理。

***隐藏网址***

Spring Security 使用非spring默认的登陆页面，是如何跳转到登陆成功页面的

发现这个问题已经在这放了那么久没人回答，为了方便后面的人，我在这里就完结一下这个问题。Spring Security 默认action="j_spring_security_check"，让很多人不理解这个请求之后会跳转到哪里去，这里我们就看***隐藏网址******隐藏网址***form-login属性详解1. login-page 自定义登录页url,默认为/login 2. login-processing-url 登录请求拦截的url,也就是form表单提交时指定的action 3. default-target-url 默认登录成功后跳转的url 4. always-use-default-target 是否总是使用默认的登录成功后跳转url 5. authentication-failure-url 登录失败后跳转的url 6. username-parameter 用户名的请求字段 默认为userName 7. password-parameter 密码的请求字段 默认为password 8. authentication-success-handler-ref 指向一个AuthenticationSuccessHandler用于处理认证成功的请求,不能和default-target-url还有always-use-default-target同时使用 9. authentication-success-forward-url 用于authentication-failure-handler-ref 10. authentication-failure-handler-ref 指向一个AuthenticationFailureHandler用于处理失败的认证请求 11. authentication-failure-forward-url 用于authentication-failure-handler-ref 12. authentication-details-source-ref 指向一个AuthenticationDetailsSource,在认证过滤器中使用看到第三条属性没？default-target-url这个属性。***隐藏网址******隐藏网址***《form-login default-target-url="/toMain.do" /》 ***隐藏网址***这样我们就可以在登录成功后调用上面对应的action，关于action返回视图，SpringMVC和Struts2这里我就不多说了。

springboot 整合springsecurity 前后端分离怎么实现登陆

首先分析一下工作量吧，因为要支持 restful 风格的接口，那么我们在判断用户是不是有权限访问的时候不仅要判断 url 还要判断 请求方式。 所以我门需要修改数据库表，因为我门的权限表还没有method 字段。由于要判断 url 和 method 所以要在CustomUserService 类的 loadUserByUsername 方法中要添加 权限的 url 和 method 。但是SimpleGrantedAuthority 只支持传入一个参数。 所以我门考虑要再写一个类 实现 GrantedAuthority 接口，并在构造函数中传入两个参数。嘻嘻。由于我们不仅要判断url 还要 判断请求方法，所以当然要修改 MyAccessDecisionManager 的decide 方法的内容了。因为：decide 方法是判定是否拥有权限的决策方法 ，三个参数的含义分别为：//authentication 是释CustomUserService中循环添加到 GrantedAuthority 对象中的权限信息集合.//object 包含客户端发起的请求的requset信息，可转换为 HttpServletRequest request = ((FilterInvocation) object).getHttpRequest();//configAttributes 为MyInvocationSecurityMetadataSource的getAttributes(Object object)这个方法返回的结果，此方法是为了判定用户请求的url 是否在权限表中，如果在权限表中，则返回给 decide 方法，用来判定用户是否有此权限。如果不在权限表中则放行。当然在 修改一下 MyInvocationSecurityMetadataSourceService 的getAttributes 方法。//此方法是为了判定用户请求的url 是否在权限表中，如果在权限表中，则返回给 decide 方法，用来判定用户是否有此权限。如果不在权限表中则放行。//因为我不想每一次来了请求，都先要匹配一下权限表中的信息是不是包含此url，我准备直接拦截，不管请求的url 是什么都直接拦截，然后在MyAccessDecisionManager的decide 方法中做 拦截还是放行的决策。5.关闭csrf 6.添加restful 风格的接口好了分析完了，接下来就是编码了。

SpringSecurity登录原理（源码级讲解）

首先会进入 UsernamePasswordAuthenticationFilter 并且设置权限为null和是否授权为false，然后进入 ProviderManager 查找支持 UsernamepasswordAuthenticationToken 的 provider 并且调用 provider.authenticate(authentication); 再然后就是 UserDetailsService 接口的实现类（也就是自己真正具体的业务了），这时候都检查过了后，就会回调 UsernamePasswordAuthenticationFilter 并且设置权限（具体业务所查出的权限）和设置授权为true（因为这时候确实所有关卡都检查过了）。

UsernamePasswordAuthenticationFilter

可以发现继承了 AbstractAuthenticationProcessingFilter ，那我们就来看下此类

1、继承了父类，父类是个过滤器，所以肯定先执行 AbstractAuthenticationProcessingFilter.doFilter() ，此方法首先判断当前的filter是否可以处理当前请求，不可以的话则交给下一个filter处理。

2、调用此抽象类的子类 UsernamePasswordAuthenticationFilter.attemptAuthentication(request, response) 方法做具体的操作。

3、最终认证成功后做一些成功后的 session 操作，比如将认证信息存到 session 等。

4、最终认证成功后的相关回调方法，主要将当前的认证信息放到 SecurityContextHolder 中并调用成功处理器做相应的操作。

1、父类的 authResult = attemptAuthentication(request, response); 触发了自类的方法。

2、此方法首先判断请求方式是不是POST提交，必须是POST

3、从请求中获取 username 和 password ，并做一些处理

4、封装 Authenticaiton 类的实现类 UsernamePasswordAuthenticationToken

5、调用 AuthenticationManager 的 authenticate 方法进行验证

1、怎么触发的？

2、 ProviderManager.authenticate(Authentication authentication);

**3、此方法遍历所有的Providers，然后依次执行验证方法看是否支持 UsernamepasswordAuthenticationToken**

4、若有一个能够支持当前token，则直接交由此 provider 处理并break。

5、若没一个 provider 验证成功，则交由父类来尝试处理

1、怎么触发的？

2、 DaoAuthenticationProvider

3、继承了 AbstractUserDetailsAuthenticationProvider

4、 AbstractUserDetailsAuthenticationProvider.authenticate() 首先调用了 user = this.retrieveUser(username, (UsernamePasswordAuthenticationToken)authentication);

5、调用我们自己的业务处理类

比如：

6、调用完 retrieveUser 方法继续回到抽象类的 authenticate 方法

7、首先做一些检查

8、调用 createSuccessAuthentication 方法进行授权成功

9、回到起点

进行session存储和成功后的处理器的调用等

只是简单说下类之间的调用顺序。

大功告成！

只需要一个html，一段配置，一个Service自己的业务类即可。

疑问：

1、接口login在哪定义的？

2、用户名 username 和密码 password 在哪接收的？

3、没有控制器怎么进入我们的 MyUserDetailsService 的方法？

解答：

1、 SpringSecurity 内置的，并且只能为 POST

2、名称不能变，必须是 username 和 password

3、自己看我上面的源码分析

2021-04-06 SpringSecurity登录 跨域JSESSIONID失效

SpringBoot + SpringSecurity + 前后端分离 （前端 127.0.0.1:8848，后端 localhost:8998） 登录和其他请求的JSESSIONID（存入cookie内）不同，导致其他请求给后端的JSESSIONID为未登录的无效SESSIONID，提示未登录。 顺序：登录(/login) ---》 组织结构(/depts) ---》 个人信息(/staff/getOne/wld) 登录：响应Cookie 组织结构：响应Cookie 个人信息：请求Cookie 后端 顺序：登录(/login) ---》 个人信息(/staff/getOne/wld) ---》 组织结构(/depts) 登录：响应Cookie 个人信息：无Cookie 组织结构：响应Cookie 后端 A、B两次的测试登录和其他的操作Cookie都不同，说明后端响应请求成功，但响应JSESSIONID并没有存入到本地，以致后序的操作拿不到Cookie中的JSESSIONID，能获取后端传来JSESSIONID的拿到了一个新的JSESSIONID（A中组织结构），不能获取后端传来JSESSIONID的也没有请求Cookie（B中个人信息）。 开启withCredentials后，服务器才能拿到你的cookie。当然后端服务器也要设置允许你获取你开启了才有用（之前有设置） login.html（登录）：没有开启 show-inform.html（个人信息）：开启 struct-tree.html（组织结构）：开启 （但是dataType没有指定，所以在A、B测试中其均有响应Cookie） SpringSecurity中登录的过滤器 其他请求的过滤器 1、每次调试前，浏览器缓存、cookie啥的清除干净，方便查找问题 2、改动要完整，要清楚是干什么的（前端login.html没有开启withCredentials是这次的主要问题）