跨域問題,解決方案-Nginx反向代理

跨域問題,解決之道

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供祁連網(wǎng)站建設(shè)、祁連做網(wǎng)站、祁連網(wǎng)站設(shè)計(jì)、祁連網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、祁連企業(yè)網(wǎng)站模板建站服務(wù),十余年祁連做網(wǎng)站經(jīng)驗(yàn),不只是建網(wǎng)站,更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

跨域問題,在日常開發(fā)過程中,是一個非常熟悉的名詞。今天的話題,結(jié)合我之前的項(xiàng)目場景,討論下《跨域問題,解決之道》。

跨域是什么

跨域問題,是由于JavaScript出于安全方面的考慮,不允許跨域調(diào)用其他頁面的對象。換句話說,只有JavaScript存在跨域問題。

什么情況下會出現(xiàn)跨域

不同源訪問,就算是跨域了喲。那什么才算同源呢?一般來說,同源,即同一來源,包括主機(jī)名、協(xié)議和端口號。

例如,

http://blog.720ui.com 和 http://docs.720ui.com ,是不同的二級域名,存在跨域問題。

http://blog.720ui.com 和 https://blog.720ui.com , 是不同的協(xié)議,存在跨域問題

http://blog.720ui.com 和 http://blog.720ui.com:4000 , 是不同的端口號,存在跨域問題。

http://blog.720ui.com/java/ 和 http://blog.720ui.com/about/, 雖然文件夾不同,但是是相同域名下,所以不存在跨域問題。

跨域問題普遍么

在現(xiàn)在前后端分離,微服務(wù)化之后,往往我們就存在許多不同的域名,這種情況下,就存在非常普遍的跨域問題。因此,跨域問題,在日常開發(fā)過程中,是一個非常熟悉的名詞。那么,我們是如何去解決跨域問題呢?

解決之道

我們是如何去解決跨域問題呢?來吧,我們進(jìn)入正題。

方案一,JSONP(廢棄)

很早很早之前,我有個項(xiàng)目曾經(jīng)使用過JSONP處理跨域問題。簡單的理解,jsonp是帶有回調(diào)函數(shù)callback的json,它是一個很棒的方案,可用于解決主流瀏覽器的跨域數(shù)據(jù)訪問的問題。但是,JSONP方案的局限性在于,JSONP只能實(shí)現(xiàn)GET請求。隨著現(xiàn)在RESTful的興起,JSONP顯得力不從心了。因?yàn)?,RESTful不僅有GET,還存在POST、PUT、PATCH、DELETE。

方案二,CORS(常用)

CORS 全稱為 Cross Origin Resource Sharing(跨域資源共享)。整個CORS通信過程,都是瀏覽器自動完成,不需要用戶參與。對于開發(fā)者來說,CORS通信與同源的AJAX通信沒有差別,代碼完全一樣。瀏覽器一旦發(fā)現(xiàn)AJAX請求跨源,就會自動添加一些附加的頭信息,但用戶不會有感覺。因此,實(shí)現(xiàn)CORS通信的關(guān)鍵是服務(wù)端。服務(wù)端只需添加相關(guān)響應(yīng)頭信息,即可實(shí)現(xiàn)客戶端發(fā)出 AJAX 跨域請求。

值得注意的是,瀏覽器必須先以 OPTIONS 請求方式發(fā)送一個預(yù)請求,從而獲知服務(wù)器端對跨源請求所支持 HTTP 方法。在確認(rèn)服務(wù)器允許該跨源請求的情況下,以實(shí)際的 HTTP 請求方法發(fā)送那個真正的請求。

我們絕大多數(shù)項(xiàng)目采取這個方案,實(shí)現(xiàn)細(xì)節(jié),不再擴(kuò)展,如果有疑問,可以關(guān)注公眾號私信,或者評論留言喲。

但是,不幸的是,CORS不支持IE8、IE9,如果產(chǎn)品不再考慮兼容IE低版本的話,可以忽略,但是如果產(chǎn)品需要兼容目前國內(nèi)還存在大量低版本的IE市場(百分之二十多),那么這個需要慎重考慮咯。

附圖,留念。

跨域問題,解決方案-Nginx反向代理

跨域問題,解決方案-Nginx反向代理

方案三,搭建中間轉(zhuǎn)發(fā)層(常用)

跨域問題的核心是什么?不同源訪問。是啊,如果我們轉(zhuǎn)換成同源請求,就不存在這個問題啦。

因此,我們之前有個項(xiàng)目,通過搭建中間層,當(dāng)然可以是java,也可以是node.js,通過將服務(wù)端的請求進(jìn)行轉(zhuǎn)發(fā),換句話說,就是dispatcher了一層,那么前端請求的地址,就被轉(zhuǎn)發(fā)了,所以很好的解決跨域問題。

當(dāng)然,如果對性能有考量的產(chǎn)品,就需要慎重選擇這個方案咯,因?yàn)槎嗔艘粚又虚g轉(zhuǎn)發(fā),不管是網(wǎng)絡(luò)開銷,還是性能負(fù)載都是有一定的影響。

方案四,Nginx反向代理(常用)

首先,產(chǎn)品需要搭建一個中轉(zhuǎn)nginx服務(wù)器,用于轉(zhuǎn)發(fā)請求。當(dāng)然,我們都是基于Nginx作為反向代理,所以當(dāng)然是水到渠成。

那么,Nginx的思路,就是通過Nginx解析URL地址的時(shí)候進(jìn)行判斷,將請求轉(zhuǎn)發(fā)的具體的服務(wù)器上。

說個思路,可能有點(diǎn)暈,我畫個圖,大家就理解了。

跨域問題,解決方案-Nginx反向代理

跨域問題,解決方案-Nginx反向代理

當(dāng)用戶請求xx.720ui.com/server1的時(shí)候,Nginx會將請求轉(zhuǎn)發(fā)給Server1這個服務(wù)器上的具體應(yīng)用,從而達(dá)到跨域的目的。

總結(jié)

跨域問題,在日常開發(fā)過程中,是一個非常熟悉的名詞。我們在開發(fā)過程中,或多或少都與它打過交道,因此,今天的話題,結(jié)合我之前的項(xiàng)目場景,以及JSONP、CORS、中間轉(zhuǎn)發(fā)層、Nginx反向代理四個方案進(jìn)行總結(jié),討論下《跨域問題,解決之道》。

解決思路

跨域問題,是由于JavaScript出于安全方面的考慮,不允許跨域調(diào)用其他頁面的對象。如果,我們將不同的域名整合到一個域,換句話說,通過子目錄的方式劃分,是不是就能解決跨域問題呢?那么,Nginx反向代理的思路,就是通過Nginx解析URL地址的時(shí)候進(jìn)行判斷,將請求轉(zhuǎn)發(fā)的具體的服務(wù)器上。

解決跨域問題

自定義本地的url請求規(guī)則 ,如 http://www.720ui.com/blog 則對應(yīng)要nginx服務(wù)轉(zhuǎn)發(fā)到http://blog.720ui.com 。

配置 nginx.conf 文件,將本地帶有特定前綴的URL接口請求轉(zhuǎn)發(fā)到要跨域的真實(shí)物理服務(wù)器上。

Nginx服務(wù)轉(zhuǎn)發(fā)請求到真實(shí)物理服務(wù)器。Nginx服務(wù)將真實(shí)物理服務(wù)器傳回的數(shù)據(jù)轉(zhuǎn)發(fā)給web端。

點(diǎn)擊獲取?附送學(xué)習(xí)進(jìn)階架構(gòu)資料、PDF書籍文檔、面試資料

跨域問題,解決方案-Nginx反向代理

跨域問題,解決方案-Nginx反向代理

當(dāng)前文章:跨域問題,解決方案-Nginx反向代理
網(wǎng)頁地址:http://www.muchs.cn/article0/ishioo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供外貿(mào)網(wǎng)站建設(shè)、ChatGPT、品牌網(wǎng)站制作全網(wǎng)營銷推廣、網(wǎng)頁設(shè)計(jì)公司、定制網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都定制網(wǎng)站建設(shè)