开发撞墙之难搞的跨域问题（CORS、SHIRO、PreFlight）

        初初实习，接触到的项目，各种过滤器、拦截器、安全框架以及封装。

        写了个小小的请求，谁知道就遇到了经典的跨域问题，首先最好的思路当然就是先分析项目运行当中请求经过的顺序，了解http请求组成部分。

问题分析： 

1）请求参数问题：

• 前端请求传Json对象则后端使用@RequestParam。
• 前端请求传Json对象的字符串则后端使用@RequestBody。
• ajax请求内容里使用了data:"value="+value，请一定要用注解对应参数。
• ajax请求中多个参数，请一定要用注解对应参数。

总结：反正谨慎一点就对了...（主要是人菜）

2）CORS过滤器

@Configuration
public class CORSConfiguration extends WebMvcConfigurerAdapter {
   @Override
   public void addCorsMappings(CorsRegistry registry){
      registry.addMapping("/**")
         .allowedMethods("*")
         .allowedOrigins("*")
         .allowedHeaders("*")
         .maxAge(3600);
      // wCredentials(false),//允许cookied携带
   }
}

3）SHIRO安全框架配置请求头OPTION内容

这里有两个概念：1.SHIRO框架    2.OPTION请求（PreFlight）

PreFlight

在正式跨域的请求前，浏览器会根据需要，发起一个“PreFlight”（也就是Option请求），用来让服务端返回允许的方法（如get、post），被跨域访问的Origin（来源，或者域），还有是否需要Credentials(认证信息）

一、为什么会出现options请求呢？

 跨域请求中，options请求是浏览器自发起的preflight request(预检请求)，以检测实际请求是否可以被浏览器接受。

preflight request请求报文中有两个需要关注的首部字段：

（1）Access-Control-Request-Method：告知服务器实际请求所使用的HTTP方法；

（2）Access-Control-Request-Headers：告知服务器实际请求所携带的自定义首部字段。

同时服务器也会添加origin header,告知服务器实际请求的客户端的地址。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。

服务器所返回的Access-Control-Allow-Methods首部字段将所有允许的请求方法告知客户端，返回将所有Access-Control-Request-Headers首部字段将所有允许的自定义首部字段告知客户端。此外，服务器端可返回Access-Control-Max-Age首部字段，允许浏览器在指定时间内，无需再发送预检请求，直接用本次结果即可。

在我们开发过程中出现的浏览器自发起的options请求就是上面的第二种情况。实际上，跨域请求中的”复杂请求”发出前会进行一次方法是options的preflight request。

二、当跨域请求是简单请求时不会进行preflight request,只有复杂请求才会进行preflight request。

复杂请求：

        1.使用方法put或者delete;

        2.发送json格式的数据（content-type: application/json）

        3.请求中带有自定义头部；

简单请求：

Mozilla对于简单请求的要求是以下三项必须都成立：

        ① 只能是Get、Head、Post方法

        ②除了浏览器自己在Http头上加的信息（如Connection、User-Agent），开发者只能加这                   几 个：Accept、Accept-Language、Content-Type等...

        ③ Content-Type只能取这几个值：

        *application/x-www-form-urlencoded

       *multipart/form-data

       *text/plain

三、为什么跨域的复杂请求需要preflight request？

复杂请求可能对服务器数据产生副作用。例如delete或者put,都会对服务器数据进行修改,所以在请求之前都要先询问服务器，当前网页所在域名是否在服务器的许可名单中，服务器允许后，浏览器才会发出正式的请求，否则不发送正式请求。

---

那么知道了OPTION请求后只需要在SHIRO的任意拦截方法中添加OPTION请求头的设置内容即可

//以下为简化后在验证用户信息的方法中添加的请求头设置内容，注意shiro拦截使用方法（注解）
@Override
	protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws Exception {
		HttpServletRequest httpRequest = (HttpServletRequest) request;
		HttpServletResponse httpResponse = (HttpServletResponse) response;
		// 处理CORS的options请求
		if (httpRequest.getMethod().equals(RequestMethod.OPTIONS.name())) {
			String origin = httpRequest.getHeader("Origin");
			httpResponse.setHeader("Access-control-Allow-Origin", origin);
			httpResponse.setHeader("Access-Control-Allow-Methods", httpRequest.getMethod());
			httpResponse.setHeader("Access-Control-Allow-Credentials", "true");
			httpResponse.setHeader("Access-Control-Allow-Headers",
					httpRequest.getHeader("Access-Control-Request-Headers"));
			httpResponse.setStatus(HttpStatus.SC_OK);
			return false;
		}
		return true;
	}

4）SHIRO过滤器

如果SHIRO还配置了过滤器那么只需要在过滤器中将你发起的请求对应的接口进行放行即可。

 @Bean("shiroFilter")
    public ShiroFilterFactoryBean shirFilter(SecurityManager securityManager) {
          ShiroFilterFactoryBean shiroFilter = new ShiroFilterFactoryBean();
          shiroFilter.setSecurityManager(securityManager);

          Map<String, String> filterMap = new LinkedHashMap<>();
          filterMap.put("/api/apiName","anon");

          shiroFilter.setFilterChainDefinitionMap(filterMap);
        return shiroFilter;
    }