資訊專欄INFORMATION COLUMN
摘要：最近寫了一些關(guān)于前后端分離項目之后，跨域相關(guān)方案的基本原理和常見誤區(qū)的帖子，主要包括和反向代理。反向代理此時后端相當于不跨域，和正常請求一致，無需額外配置。
最近寫了一些關(guān)于前后端分離項目之后，跨域相關(guān)方案的基本原理和常見誤區(qū)的帖子，主要包括CORS和Nginx反向代理。這兩種方案項目中都有在用，各有優(yōu)缺，關(guān)于具體使用哪種方案，大家的觀點也不大一致，本文主要就此展開一下，從前后端及服務(wù)器配置、安全性、移植靈活性、擴展性等方面詳細對比一下兩種方案的優(yōu)缺，以便于后期在方案選型上對大家有所幫助。
CORS方案：跨域時部分瀏覽器默認不攜帶cookie，因此為了攜帶cookie需要設(shè)置一下xmlhttprequest的withCrendetails屬性，使用vue-resouce時設(shè)置如下
Vue.http.options.credentials = true
用axios時，可以在攔截器中設(shè)置如下
axios.interceptors.request.use((config) => {
config.withCredentials = true
return config
}, (error) => {
return Promise.reject(error)
})
使用原生XMLHttpRequest對象時如下，
var xhr = new XMLHttpRequest(); xhr.withCredentials = true;
如果不需要傳遞cookie，最好置成false，避免不嗯瀏覽器默認允許cookie的攜帶。
Nginx反向代理：此時前端相當于不跨域，和正常請求一致，無需額外配置。
CORS方案： 后端需要包裝ACA系列header，
"Access-Control-Allow-Origin" "*"; "Access-Control-Allow-Credentials" "true"; "Access-Control-Allow-Headers" "X-Requested-With";
除此以外無需額外配置。
Nginx反向代理：此時后端相當于不跨域，和正常請求一致，無需額外配置。
CORS方案： 無。
Nginx反向代理：該方案跨域工作都集中在nginx服務(wù)器上，配置如下
...
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
location /api {
proxy_pass https://b.test.com; # 設(shè)置代理服務(wù)器的協(xié)議和地址
proxy_cookie_domain b.test.com a.test.com; # 修改cookie，針對request和response互相寫入cookie
}
...
原理移步nginx反向代理跨域基本配置與常見誤區(qū)、nginx配置解析之客戶端真實IP的傳遞
安全性CORS方案： 由于此時瀏覽器會默認添加origin屬性，服務(wù)端可以直接查到請求來源，便于控制來源、屏蔽黑名單鏈接。同時服務(wù)端域名和端口會暴露出來。
Nginx反向代理：反向代理方案中沒有默認的origin頭部可以使用，但是可以通過X-Forward-For頭部查看客戶端及各級代理ip，也可以實現(xiàn)一定程度的回溯追蹤和黑名單屏蔽。由于反向代理中，可以采用內(nèi)網(wǎng)地址訪問接口服務(wù)器，這樣可以一定程度上保護接口服務(wù)器不暴露出來。
CORS方案： 只需要在代碼或者配置中心進行黑白名單配置即可，方便移植和擴展。
Nginx反向代理：不同環(huán)境服務(wù)域名可能不一致，因此nginx配置也各不相同，不便于移植。而對于擴展性，當存在新的項目需要訪問接口服務(wù)器時，需要首先訪問nginx中server指定的域名，再由server域名反向代理到接口服務(wù)器，比如
server {
listen 8443;
server_name a.test.com;
client_max_body_size 100m;
ssl ...
location /micro{
proxy_pass https://b.test.com; #反向代理
proxy_cookie_domain b.test.com a.test.com; #修改cookie
add_header "Access-Control-Allow-Origin" "htps://c.test.com";
add_header "Access-Control-Allow-Credentials" "true";
add_header Access-Control-Allow-Headers X-Requested-With;
}
}
這個時候跨域模型就變了，由單純的a.test.com反向代理到b.test.com，變成了a.test.com反向代理到b.test.com以及c.test.comCORS到a.test.com再反向代理到b.test.comd的情況。這個有點繞，但仔細想一下就會明白。這無疑增加了后期的維護成本。
綜合對比綜合以上，我們大致可以得到如下圖標
| Item | CORS | Nginx反向代理 |
|---|---|---|
| 代碼配置--前端 | credentials=true | 無 |
| 代碼配置--后臺 | setHeader:ACA-Origin、ACA-Method、ACA-Credentials等 | 無 |
| 服務(wù)器配置 | 無 | Nginx配置 |
| 移植靈活性 | 高、無需額外配置 | 低、每套環(huán)境配置可能均不相同 |
| 安全性 | 來源可控、直接追溯 | X-Forwarded-For追溯多級來源 |
| 新項目擴展 | 黑白名單控制 | 更新配置，跨域模型會產(chǎn)生變化 |
綜上呢，對于公共基礎(chǔ)服務(wù)，由于涉及到對接的前端項目可能比較多，開發(fā)測試部署環(huán)境也比較多，整體上來講我更傾向于推薦大家使用CORS方案。而對于一些對立性強的小項目，使用nginx則可以降低你的開發(fā)成本，快速發(fā)開快速上線。具體使用當然也要結(jié)合工作實際，按需使用吧。
此外對于Nginx反向代理方案使用時，推薦使用內(nèi)部域名/ip作為接口服務(wù)器的入口，盡量不要暴露到外面，以免出現(xiàn)不必要的安全問題。
～本篇完～歡迎大家一起討論～
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/40097.html
摘要：反向代理服務(wù)器對于客戶端而言它就像是原始服務(wù)器，并且客戶端不需要進行任何特別的設(shè)置。使用反向代理可能訪問網(wǎng)頁相對于之前響應會比較慢 標簽： Nginx,跨域 問題 在之前的分享的跨域資源共享的文章中，有提到要注意跨域時，如果要發(fā)送Cookie，Access-Control-Allow-Origin就不能設(shè)為*，必須指定明確的、與請求網(wǎng)頁一致的域名。在此次項目開發(fā)中與他人協(xié)作中就遇到...
摘要：反向代理服務(wù)器對于客戶端而言它就像是原始服務(wù)器，并且客戶端不需要進行任何特別的設(shè)置。使用反向代理可能訪問網(wǎng)頁相對于之前響應會比較慢 標簽： Nginx,跨域 問題 在之前的分享的跨域資源共享的文章中，有提到要注意跨域時，如果要發(fā)送Cookie，Access-Control-Allow-Origin就不能設(shè)為*，必須指定明確的、與請求網(wǎng)頁一致的域名。在此次項目開發(fā)中與他人協(xié)作中就遇到...
閱讀 2631·2021-11-17 17:00
閱讀 1884·2021-10-11 10:57
閱讀 3751·2021-09-09 11:33
閱讀 921·2021-09-09 09:33
閱讀 3558·2019-08-30 14:20
閱讀 3324·2019-08-29 11:25
閱讀 2809·2019-08-26 13:48
閱讀 747·2019-08-26 11:52
