最近開發了一個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到如上三個亮點了嗎？如果你也跟我一樣喜歡解決問題，可以一鍵三連，關注我就可以更及時看到我的精彩分享啦！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!