CORS跨域與Nginx反向代理跨域優劣對比

yiliang 發布于2019-07-25 14:26 / 2909人閱讀

摘要：最近寫了一些關于前后端分離項目之后，跨域相關方案的基本原理和常見誤區的帖子，主要包括和反向代理。反向代理此時后端相當于不跨域，和正常請求一致，無需額外配置。

最近寫了一些關于前后端分離項目之后，跨域相關方案的基本原理和常見誤區的帖子，主要包括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
}       
...

原理移步nginx反向代理跨域基本配置與常見誤區、nginx配置解析之客戶端真實IP的傳遞

安全性

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作為接口服務器的入口，盡量不要暴露到外面，以免出現不必要的安全問題。

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

云服務器 GPU云服務器阿里云跨域與反向服務器代理 nginx服務器跨域 nginx反向代理 php代理代理跨域

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/40097.html

徹底弄懂跨域問題

摘要：用于告知瀏覽器可以將預先檢查請求返回結果緩存的時間，在緩存有效期內，瀏覽器會使用緩存的預先檢查結果判斷是否發送跨域請求。跨域，老生常談的問題簡述作為一只前端菜鳥，跨域方面只懂得JSONP和CORS，并未曾深入了解。但隨著春招越來越近，就算是菜鳥也要猛振翅膀。近幾日仔細研究了跨域問題，寫下這篇文章，希望對開發者們有所幫助。在讀本文前，希望您對以下知識略有了解。瀏覽器同源策略 n...

rose 2019-07-25 14:36 評論0 收藏0
徹底弄懂跨域問題

摘要：瀏覽器同源策略我們為何要研究跨域問題因為瀏覽器的同源策略規定某域下的客戶端在沒明確授權的情況下，不能讀寫另一個域的資源。跨域，老生常談的問題簡述作為一只前端菜鳥，跨域方面只懂得JSONP和CORS，并未曾深入了解。但隨著春招越來越近，就算是菜鳥也要猛振翅膀。近幾日仔細研究了跨域問題，寫下這篇文章，希望對開發者們有所幫助。在讀本文前，希望您對以下知識略有了解。瀏覽器同源策略 n...

CoorChice 2019-08-23 14:41 評論0 收藏0
利用Nginx反向代理解決跨域問題

摘要：反向代理服務器對于客戶端而言它就像是原始服務器，并且客戶端不需要進行任何特別的設置。使用反向代理可能訪問網頁相對于之前響應會比較慢標簽： Nginx,跨域問題在之前的分享的跨域資源共享的文章中，有提到要注意跨域時，如果要發送Cookie，Access-Control-Allow-Origin就不能設為*，必須指定明確的、與請求網頁一致的域名。在此次項目開發中與他人協作中就遇到...

EscapedDog 2019-08-23 14:13 評論0 收藏0
利用Nginx反向代理解決跨域問題

摘要：反向代理服務器對于客戶端而言它就像是原始服務器，并且客戶端不需要進行任何特別的設置。使用反向代理可能訪問網頁相對于之前響應會比較慢標簽： Nginx,跨域問題在之前的分享的跨域資源共享的文章中，有提到要注意跨域時，如果要發送Cookie，Access-Control-Allow-Origin就不能設為*，必須指定明確的、與請求網頁一致的域名。在此次項目開發中與他人協作中就遇到...

YanceyOfficial 2019-07-25 14:36 評論0 收藏0