shiro的前后端分离模式
前言：在上一篇《shiro的简单认证和授权》中介绍了shiro的搭建，默认情况下，shiro是通过设置cookie，使前端请求带有“JSESSION”cookie，后端通过获取该cookie判断用户是否登录以及授权。但是在前后端分离模式中，前后端不在同一个域内，后端无法自动给请求添加cookie，因而默认的模式不能实现正常的认证授权逻辑。
我们可以将subject的sessionId通过登录成功的请求返回给前端，前端获取sessionId后在每个请求的header中带上sessionId（token），后端通过继承DefaultWebSessionManager类，实现自定义的session管理器，改写getSession的方法，改在header中获取sessionId进行后续认证与授权。
以下例子只是demo，不注重正式开发细节，例如返回值封装，请求Restful风格等等，正式项目中注意甄别
1.登录成功，将sessionId返回给前端
/*** 登录接口* @param username* @param password* @return*/@GetMapping("/login")public String login(String username,String password){// 获取当前主体Subject subject = SecurityUtils.getSubject();// 构建登录token，login方法进入中进入我们自定义的realm的doGetAuthenticationInfo方法UsernamePasswordToken usernamePasswordToken = new UsernamePasswordToken(username, password);subject.login(usernamePasswordToken);String token = (String) SecurityUtils.getSubject().getSession().getId();return "登陆成功,token为："+token;}
2.前端携带token请求
前端将获取到的token写到sessionStorage或者localStorage，然后请求时添加到请求头中，例如axios请求例子
axios({method:"GET",url:"http://127.0.0.1:8080/testIndex",headers:{'Content-Type':' application/json','token':'bd9ae5c3-570f-4ed2-ac57-8f935655ef55', // token从localStorage中获取},withCredentials: true,}).then((r)=>{console.log(r)})
3.继承DefaultWebSessionManager
Shiro中DefaultWebSessionManager管理shiro的session会话，包括设置cookie，获取前端携带的shiro的sessionId等等。我们可以重写其方法，实现自己的逻辑，最后添加到SecurityManager中，例如重写getSessionId方法，改为从header中获取sessionId。
public class CustomSessionManager extends DefaultWebSessionManager {private static final String HEADER_TOKEN = "token";private static final String REFERENCED_SESSION_ID_SOURCE = "Stateless request";public CustomSessionManager() {super();}@Overrideprotected Serializable getSessionId(ServletRequest request, ServletResponse response) {String id = WebUtils.toHttp(request).getHeader(HEADER_TOKEN);if (!StringUtils.isEmpty(id)) {request.setAttribute(ShiroHttpServletRequest.SESSION_ID_URL_REWRITING_ENABLED, isSessionIdUrlRewritingEnabled());request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_SOURCE, REFERENCED_SESSION_ID_SOURCE);request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID, id);request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_IS_VALID, Boolean.TRUE);return id;} else {return super.getSessionId(request, response);}}
}
4. 在ShiroConfig中加入SecurityManager
在ShiroConfig中，创建自定义的SessionManager实例，然后添加到SecurityManager
/*** sessionManager*/public DefaultWebSessionManager sessionManager() {
// DefaultWebSessionManager sessionManager = new DefaultWebSessionManager();CustomSessionManager sessionManager = new CustomSessionManager();sessionManager.setSessionIdUrlRewritingEnabled(false);sessionManager.setSessionDAO(redisSessionDAO());sessionManager.setSessionIdCookieEnabled(false);return sessionManager;}/*** SecurityManager*/@Beanpublic SecurityManager securityManager(Realm myRealm){DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager();//设置一个Realm，这个Realm是最终用于完成我们的认证号和授权操作的具体对象securityManager.setRealm(myRealm);securityManager.setSessionManager(sessionManager());securityManager.setCacheManager(cacheManager());return securityManager;}
5.跨域设置
前后端分离肯定离不开跨域设置，跨域有多重设置方法，这里不赘述
/*** 解决跨域问题*/
@Configuration
public class CorsConfig implements WebMvcConfigurer {@Overridepublic void addCorsMappings(CorsRegistry registry) {registry.addMapping("/**").allowedOriginPatterns("*").allowedMethods("GET", "HEAD", "POST", "PUT", "DELETE", "OPTIONS").allowCredentials(true).maxAge(3600).allowedHeaders(CorsConfiguration.ALL);
// .allowedHeaders("*"); }
}
6.添加过滤器
这里是一个坑，我以为完成以上步骤就可以实现前后端分离，但是测试后发现，有一些请求符合预期，但是有一些请求却报跨域，甚至乎不是寻常的报跨域
浏览器控制台输出
如果是跨域的话，按道理讲应该所有请求都会报跨域，但是login请求没有报
那么就应该跟shiro的FilterChainDefinitionMap有关，只有拦截做验证的请求才会报错。以为是菜狗，查了好久，都没有找到正确答案。然后在调试时发现报错的请求不是我写的get请求，而是options请求。
事实上在这之前我只听说过options，并没去了解options请求的作用，看到报差后才去百度一下
Options 请求是 HTTP 协议中的一种请求方法，它用于获取服务器支持的请求方法和其他选项。Options 请求通常不会包含实际的请求数据，而是用于获取服务器的元数据信息。
Options 请求的主要作用包括：
获取服务器支持的请求方法：Options 请求可以获取服务器支持的请求方法，例如 GET、POST、PUT、DELETE 等。这对于客户端来说非常有用，因为它可以确定服务器是否支持特定的请求方法。
检查服务器的能力：Options 请求可以检查服务器的能力，例如是否支持跨域请求、是否支持特定的 HTTP 头、是否支持特定的内容类型等。
探测服务器：Options 请求可以用于探测服务器，例如确定服务器的版本、操作系统、服务器软件等信息。这对于安全测试和漏洞扫描非常有用。
Options 请求通常被视为一种安全的请求方法，因为它不会对服务器产生实际的影响。但是，服务器可能会限制 Options 请求的使用，例如限制请求频率或限制请求的来源。因此，在使用 Options 请求时，应该遵守服务器的规定，并确保请求是合法和必要的。
原来options这么重要，那报的跨域肯定就是这个options搞的鬼了。当然就算知道问题所在，我这菜狗也是想不到解决方案的，但至少会百度。
然后就查到以下文章
[SpringBoot+Shiro放行OPTIONS请求，解决跨域问题] https://blog.csdn.net/qq_41289165/article/details/121529166
第一步，新建一个Filter继承Shiro的UserFilter，里面的preHandle方法对options请求直接放行。还有其他逻辑看注释，这里不赘述
@Slf4j
public class ShiroUserFilter extends UserFilter {/*** 在访问过来的时候检测是否为OPTIONS请求，如果是就直接返回true*/@Overrideprotected boolean preHandle(ServletRequest request, ServletResponse response) throws Exception {HttpServletResponse httpResponse = (HttpServletResponse) response;HttpServletRequest httpRequest = (HttpServletRequest) request;if (httpRequest.getMethod().equals(RequestMethod.OPTIONS.name())) {log.info("OPTIONS放行");setHeader(httpRequest,httpResponse);return true;}return super.preHandle(request,response);}/*** 该方法会在验证失败后调用，这里由于是前后端分离，后台不控制页面跳转* 因此重写改成传输JSON数据*/@Overrideprotected void saveRequestAndRedirectToLogin(ServletRequest request, ServletResponse response) throws IOException {saveRequest(request);setHeader((HttpServletRequest) request,(HttpServletResponse) response);PrintWriter out = response.getWriter();//自己控制返回的json数据Map map = new HashMap();map.put("code",500);map.put("message","Shiro验证失败");out.println(map);out.flush();out.close();}/*** 为response设置header，实现跨域*/private void setHeader(HttpServletRequest request, HttpServletResponse response){//跨域的header设置response.setHeader("Access-control-Allow-Origin", request.getHeader("Origin"));response.setHeader("Access-Control-Allow-Methods", request.getMethod());response.setHeader("Access-Control-Allow-Credentials", "true");response.setHeader("Access-Control-Allow-Headers", request.getHeader("Access-Control-Request-Headers"));//防止乱码，适用于传输JSON数据response.setHeader("Content-Type","application/json;charset=UTF-8");response.setStatus(HttpStatus.OK.value());}
}
第二步，将该Filter添加到FilterFactoryBean中
在ShiroConfig中的shiroFilterFactoryBean方法中，添加shiroFilter.getFilters().put("authc", new ShiroUserFilter());
@Beanpublic ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager){ShiroFilterFactoryBean shiroFilter = new ShiroFilterFactoryBean();shiroFilter.setSecurityManager(securityManager);// 添加自定义filtershiroFilter.getFilters().put("authc", new ShiroUserFilter());// 认证失败（用户没登录时）会重定向到这个loginUrlshiroFilter.setLoginUrl("/");// 授权失败重定向路径shiroFilter.setUnauthorizedUrl("/noPermission");// 定义一个LinkHashMap，保存认证的路径和规则Map<String,String> map = new LinkedHashMap();// key为uri，anon为标识符，标识不需要验证map.put("/login","anon");// authc表示Authentication，即是需要认证map.put("/admin/**","authc");// key “/**"表示所有uri，”/**“必须写在最后，如果不写该项，默认放行所有没配置的urimap.put("/**","authc");// 将该map设置进shiroFiltershiroFilter.setFilterChainDefinitionMap(map);return shiroFilter;}
7.测试
至此，前后端分离实现完毕
options请求正常
验证通过的请求能正常访问接口
补充
以上已经实现shiro的前后端分离功能，这里再补充下，将shiro默认的set-cookie行为去掉，只需要设置SessionManager的SessionIdCookieEnabled为false即可，如下在ShiroConfig中的SessionManager
public DefaultWebSessionManager sessionManager() {CustomSessionManager sessionManager = new CustomSessionManager();sessionManager.setSessionIdUrlRewritingEnabled(false);sessionManager.setSessionDAO(redisSessionDAO());// 将shiro默认的set-cookie行为去掉sessionManager.setSessionIdCookieEnabled(false);return sessionManager;}
至此，全篇结束
