同源策略（ same origin policy ）是浏览器安全的基石。在同源策略的限制下，非同源的网站之间不能发送 ajax 请求的。
为了解决这个问题， w3c 提出了跨源资源共享，即 CORS(Cross-Origin Resource Sharing)。
CORS 做到了两点：
基于这两点， CORS 将请求分为两类：简单请求和非简单请求。
可以先看下 CORS 出现前的情况：跨源时能够通过 script 或者 image 标签触发 GET 请求或通过表单发送一条 POST 请求，但这两种请求 HTTP 头信息中都不能包含任何自定义字段。
简单请求对应该规则，因此对简单请求的定义为：
请求方法是 HEAD、GET 或 POST 且 HTTP 头信息不超过以下几个字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type（只限于 application/x-www-form-urlencoded、multipart/form-data、text/plain）。
比如有一个简单请求：
GET /test HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, sdch, br
Origin: http://www.examples.com
Host: www.examples.com
对于这样的简单请求， CORS 的策略是请求时，在头信息中添加一个 Origin 字段，服务器收到请求后，根据该字段判断是否允许该请求。
Access-Control-Allow-Origin 字段，并返回正确的结果Access-Control-Allow-Origin 字段。浏览器先于用户得到返回结果，根据有无 Access-Control-Allow-Origin 字段来决定是否拦截该返回结果。
对于 CORS 出现前的一些服务， CORS 对他们的影响分两种情况：
Access-Control-Allow-Origin，因此返回结果会被浏览器拦截，接口依旧不可以被 ajax 跨源访问。可以看出， CORS 的出现，没有对”旧的“服务造成任何影响。
另外，除了提到的 Access-Control-Allow-Origin 还有几个字段用于描述 CORS 返回结果：
除了简单请求之外的请求，就是非简单请求。
对于非简单请求的跨源请求，浏览器会在真实请求发出前，增加一次 OPTION 请求，称为预检请求（ preflight request ）。预检请求将真实请求的信息，包括请求方法、自定义头字段、源信息添加到 HTTP 头信息字段中，询问服务器是否允许这样的操作。
比如对于 DELETE 请求：
OPTIONS /test HTTP/1.1
Origin: http://www.examples.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: X-Custom-Header
Host: www.examples.com
与 CORS 相关的字段有：
Access-Control-Request-Method: 真实请求使用的 HTTP 方法。Access-Control-Request-Headers: 真实请求中包含的自定义头字段。服务器收到请求时，需要分别对 Origin 、 Access-Control-Request-Method 、 Access-Control-Request-Headers 进行验证，验证通过后，会在返回 Http 头信息中添加
Access-Control-Allow-Origin: http://www.examples.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000
他们的含义分别是：
当预检请求通过后，浏览器会发送真实请求到服务器。这就实现了跨源请求
通过WebMvcConfigurerAdapter#addCorsMappings去配置
public class WebConfig extends WebMvcConfigurerAdapter { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedHeaders("*") .allowedMethods("*") .allowedOrigins("*"); } }
通过自定义Filter
@Bean public FilterRegistrationBean corsFilter() { UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("*"); config.setAllowCredentials(true); config.addAllowedHeader("*"); config.addAllowedMethod("*"); source.registerCorsConfiguration("/**", config); FilterRegistrationBean bean = new FilterRegistrationBean(new CorsFilter(source)); bean.setOrder(0); return bean; }
这两种方式实现的机制完全不一样，也就是产生作用的生命周期不一样。
前端已经通过javascript的接口，从keycloak验证并获得了token，keycloak作为单点登录系统，理论上是可以通过token登录并验证任何一个后端服务，但是，当按照文档上面的描述，正确配置springboot及security，后端依然无法通过token的验证。但当将前后端使用同一个IP和端口时，请求正常。
方案一，配置Spring security策略，不拦截OPTIONS请求
HttpSecurity#authorizeRequests().antMatchers(HttpMethod.OPTIONS).permitAll()
方案二，自定义CorsFilter，设置order为最高优先级或者其他，只需要优先级比Spring security的order高便好。
好的博文推荐：
原文：https://www.cnblogs.com/EST-woah/p/10666560.html