最近开发了一个Spring Boot Nginx LayuiAdmin项目，在上线时遇到了如下血淋淋的战场，请君细看。
Web网站开发遇到的坑有哪些？
首先在测试环境时，请求都能够从LayuiAdmin的一个网页中发起admin.req到Spring Boot项目，而且只要登录之后，服务器会向前端响应access_token的值，只要需要登录的接口，都会带上这个access_token的请求头的值。
不料，被我发现了第一个战场亮点如下：
如果Spring Boot 中没有配置CORS【如果还不懂CORS,可以查看我之前的文章】，则前端向后端发送请求时，前端的IP，协议和端口和后端的IP，协议和端口只要有一个不一致，都不能够正常请求，会遇到CORS错误，故在Spring Boot 中增加如下配置类：
@Configuration
public class GlobalWebConfig extends WebMvcConfigurationSupport {
/**
* 解决CORS的问题
*
* @param registry cors注册对象
*/
@Override
protected void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedHeaders("*")
.allowedMethods("*")
.allowedOrigins("*")
.allowCredentials(true)
// 向前端js暴露的请求头
.exposedHeaders("access_token");//此处是第二个战场较量处
}
}
为了解决IP和端口的一致，则需要在Nginx中配置路径，也就是说前端和后端都在同一个Server中配置，只是后面的路径不一样，所以增加了如下Nginx的配置
server {
listen 443 ssl;
server_name clbgw.vip;
underscores_in_headers on;# 此处是第三个战场较量处
ssl_certificate cert/clbgw.vip.pem;
ssl_certificate_key cert/clbgw.vip.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location /encry/ {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers "*";
add_header Access-Control-Allow-Methods "GET,POST,PUT,DEELETE,OPTIONS";
proxy_pass http://xckyEncry/;
}
location /layui/ {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers "*";
add_header Access-Control-Allow-Methods "GET,POST,PUT,DEELETE,OPTIONS";
alias html/layui/;
}
}
这样前端路径：https://clbgw.vip/layui 和后端路径 https://clbgw.vip/encry 就同协议，同IP和同端口,也就解决了CORS的根本性问题了。
解决完第一个问题就结束了吗，不，还有第二个容易忽视的亮点。
再说下关于后端返回的access_token响应头为什么在前端的js中无法获取？那是因为Spring Boot没有暴露响应头或者请求头，故在CORS的基础上增加如下代码：
.exposedHeaders("access_token");
那么这第二个问题也就轻松解决了。
那么再赠送第三个战场发现的亮点，那就是更加细小的问题：【access_token】这个请求头有没有觉得很可疑。
这第三个亮点就是这个access_token的下划线，这也是我这次解析和分析许久的问题，但是最终的解决办法就是在nginx中的http节点出增加如下配置：
underscores_in_headers on;
默认nginx是会忽略请求头中包含的下划线请求头的key，那么解决办法就至少有两个，一个是请求头的key不使用下划线，比如access-token 或者accessToken 或者token都是可以的，就能够避免这个问题了，当然另外一个简单的办法就是在nginx增加如上开启下划线的请求头配置了。
现在你get到如上三个亮点了吗？如果你也跟我一样喜欢解决问题，可以一键三连，关注我就可以更及时看到我的精彩分享啦！
,
