簡單對比一下CORS跨域與Nginx反向代理跨域優劣

木子墨發表於2019-08-19
CORS跨域Nginx

不好意思又來炒冷飯了。。。請拿簡歷來砸我。。。螞蟻金服-芝麻信用招人啦 前端P6/7，崗位JD參考，名額有限，快來人啊。。。

前面寫了一些關於前後端分離專案之後，跨域相關方案的基本原理和常見誤區的帖子，主要包括CORS和Nginx反向代理。這兩種方案專案中都有在用，各有優缺，關於具體使用哪種方案，大家的觀點也不大一致，本文主要就此展開一下，從前後端及伺服器配置、安全性、移植靈活性、擴充套件性等方面詳細對比一下兩種方案的優缺，以便於後期在方案選型上對大家有所幫助。

一、前端配置

CORS方案：跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要設定一下xmlhttprequest的withCrendetails屬性，使用vue-resouce時設定如下

Vue.http.options.credentials = true
複製程式碼

用axios時，可以在攔截器中設定如下

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伺服器上，配置如下

...
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; # 設定代理伺服器的協議和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，針對request和response互相寫入cookie
}       
...
複製程式碼

原理可以看下前面兩篇文章

四、安全性

CORS方案： 由於此時瀏覽器會預設新增origin屬性，服務端可以直接查到請求來源，便於控制來源、遮蔽黑名單連結。同時服務端域名和埠會暴露出來。 Nginx反向代理：反向代理方案中沒有預設的origin頭部可以使用，但是可以通過X-Forward-For頭部檢視客戶端及各級代理ip，也可以實現一定程度的回溯追蹤和黑名單遮蔽。由於反向代理中，可以採用內網地址訪問介面伺服器，這樣可以一定程度上保護介面伺服器不暴露出來。

五、移植靈活性、擴充套件性

CORS方案： 只需要在程式碼或者配置中心進行黑白名單配置即可，方便移植和擴充套件。 Nginx反向代理：不同環境服務域名可能不一致，因此nginx配置也各不相同，不便於移植。而對於擴充套件性，當存在新的專案需要訪問介面伺服器時，需要首先訪問nginx中server指定的域名，再由server域名反向代理到介面伺服器，比如

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等 無
伺服器配置 無 Nginx配置
移植靈活性 高、無需額外配置 低、每套環境配置可能均不相同
安全性 來源可控、直接追溯 X-Forwarded-For追溯多級來源
新專案擴充套件 黑白名單控制 更新配置，跨域模型會產生變化

對比結論

綜上呢，對於公共基礎服務，由於涉及到對接的前端專案可能比較多，開發測試部署環境也比較多，整體上來講我更傾向於推薦大家使用CORS方案。而對於一些對立性強的小專案，使用nginx則可以降低你的開發成本，快速發開快速上線。具體使用當然也要結合工作實際，按需使用吧。 此外對於Nginx反向代理方案使用時，推薦使用內部域名/ip作為介面伺服器的入口，儘量不要暴露到外面，以免出現不必要的安全問題。

emmm最近我們還在招人了，螞蟻金服-芝麻信用招前端P6/7！機會難得！加油啊！你可以的！，大廠你懂的，獎金分你一半啊，感興趣的快來試試吧，有興趣微信聊聊的加我哈heiohiio，簡歷直接丟我郵箱也可以啊～heioray@sina.com

～本篇完～歡迎大家一起討論～

相關文章