nginx后面有个斜杠和没斜杠区别(请求头的真正较量之Nginx与下划线)
最近开发了一个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到如上三个亮点了吗?如果你也跟我一样喜欢解决问题,可以一键三连,关注我就可以更及时看到我的精彩分享啦!
,免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com