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

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

---

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

---

1、前端配置

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反向代理：此時前端至關於不跨域，和正常請求一致，無需額外配置。

2、後端配置

CORS方案： 對於簡單請求後端須要包裝ACA系列header，

'Access-Control-Allow-Origin' '*';
'Access-Control-Allow-Credentials' "true"; 
'Access-Control-Allow-Headers' 'X-Requested-With';
複製代碼

而對於複雜跨域請求，則還須要處理一步預檢的流程。

Nginx反向代理：此時後端至關於不跨域，和正常請求一致，無需額外配置。

3、服務器配置

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
}       
...
複製代碼

原理能夠看下前面兩篇文章

4、安全性

CORS方案： 因爲此時瀏覽器會默認添加origin屬性，服務端能夠直接查到請求來源，便於控制來源、屏蔽黑名單連接。同時服務端域名和端口會暴露出來。 Nginx反向代理：反向代理方案中沒有默認的origin頭部可使用，可是能夠經過X-Forward-For頭部查看客戶端及各級代理ip，也能夠實現必定程度的回溯追蹤和黑名單屏蔽。因爲反向代理中，能夠採用內網地址訪問接口服務器，這樣能夠必定程度上保護接口服務器不暴露出來。

5、移植靈活性、擴展性

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

---

～本篇完～歡迎你們一塊兒討論～