1.跨域问题描述: 本人在基于Oauth2.0做鉴权/授权时，配合前端联调接口时，已经让前端请求时的请求头带上key：Authorization，但是前台报错为跨域问题，后台报错鉴权失败，于是跟踪错误，发现在网关处从header中一直拿不到这个 Authorization 这个属性的值（因为oauth 2的密码模式是需要请求头中带有token才能够完成鉴权），具体错误如下图所示：

上图中可以明显看到请求中是存在 Authorization 这个属性的，但是从后台图片看是并没有拿到这个属性的：

2.问题分析经过: 本人继续向下查找原因，发现通过 HttpRequest的api:getHeaderNames()可以找到请求头中的所有header属性，如下图：

于是猜想是否有一层转换是将请求头中所有的key属性转化了小写，于是继续尝试 request.getHeader(“authorization”),但是结果还是出乎意料，返回结果也是空，于是开始从头理思路：

从前台开始报错为跨域问题，查看发生错误请求的类型为Preflighted，这让本人感到疑惑，于是查阅资料：

查阅带预检(Preflighted)的跨域请求跨域原因有如下两种：

1). 除GET、HEAD和POST(only with application/x-www-form-urlencoded, multipart/form-data, text/plain Content-Type)以外的其他HTTP方法。 2). 请求中出现自定义HTTP头部。 以上摘自博客链接

此时豁然开朗，因为基于Oauth2的协议需要在请求中带上 Authorization 及其对应的token，所以自定义了请求头，且请求方不同源，所以浏览器（本次问题使用google浏览器）会发送两次请求：

1). 带预检(Preflighted)的跨域请求，此时请求类型为OPTIONS

2). 带真实数据的请求,此时才是我们真实想要的GET/POST请求

3.验证问题猜想: 如下图，断点处请求类型确实为 OPTIONS

4.解决方案: 既然已经明确了问题所在，解决方案便随之而出了，由于本人是基于zuul网关做的鉴权/授权，所以解决方案也是基于zuul，仅提供参考： 1). 配置跨域过滤器，优先级最高，生效在路由前，判断如果是带预检的请求，则在响应头中放入允许跨域相关的属性，然后不再向下路由，具体代码如下：

二. 另外附单体服务解决跨域方案 以下需要注意的点为 @Order(Integer.MIN_VALUE) ,这行代码的意思是将此过滤器的作用在所有过滤链最前端，至于原因本人会单独开一篇博客讨论。