摘要:關(guān)于,強烈推薦閱讀跨域資源共享詳解阮一峰另外,這里也整理了一個實現(xiàn)原理圖簡化版如何判斷是否是簡單請求瀏覽器將請求分成兩類簡單請求和非簡單請求。
前言
從剛接觸前端開發(fā)起,跨域這個詞就一直以很高的頻率在身邊重復出現(xiàn),一直到現(xiàn)在,已經(jīng)調(diào)試過N個跨域相關(guān)的問題了,16年時也整理過一篇相關(guān)文章,但是感覺還是差了點什么,于是現(xiàn)在重新梳理了一下。
個人見識有限,如有差錯,請多多見諒,歡迎提出issue,另外看到這個標題,請勿噴~
題綱關(guān)于跨域,有N種類型,本文只專注于ajax請求跨域(,ajax跨域只是屬于瀏覽器"同源策略"中的一部分,其它的還有Cookie跨域iframe跨域,LocalStorage跨域等這里不做介紹),內(nèi)容大概如下:
什么是ajax跨域
原理
表現(xiàn)(整理了一些遇到的問題以及解決方案)
如何解決ajax跨域
JSONP方式
CORS方式
代理請求方式
如何分析ajax跨域
http抓包的分析
一些示例
什么是ajax跨域 ajax跨域的原理ajax出現(xiàn)請求跨域錯誤問題,主要原因就是因為瀏覽器的“同源策略”,可以參考
瀏覽器同源政策及其規(guī)避方法(阮一峰)
CORS請求原理CORS是一個W3C標準,全稱是"跨域資源共享"(Cross-origin resource sharing)。它允許瀏覽器向跨源服務器,發(fā)出XMLHttpRequest請求,從而克服了AJAX只能同源使用的限制。
基本上目前所有的瀏覽器都實現(xiàn)了CORS標準,其實目前幾乎所有的瀏覽器ajax請求都是基于CORS機制的,只不過可能平時前端開發(fā)人員并不關(guān)心而已(所以說其實現(xiàn)在CORS解決方案主要是考慮后臺該如何實現(xiàn)的問題)。
關(guān)于CORS,強烈推薦閱讀?
跨域資源共享 CORS 詳解(阮一峰)
另外,這里也整理了一個實現(xiàn)原理圖(簡化版):
如何判斷是否是簡單請求?瀏覽器將CORS請求分成兩類:簡單請求(simple request)和非簡單請求(not-so-simple request)。只要同時滿足以下兩大條件,就屬于簡單請求。
請求方法是以下三種方法之一:HEAD,GET,POST
HTTP的頭信息不超出以下幾種字段:
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type(只限于三個值application/x-www-form-urlencoded、 multipart/form-data、text/plain)
凡是不同時滿足上面兩個條件,就屬于非簡單請求。
ajax跨域的表現(xiàn)說實話,當初整理過一篇文章,然后作為了一個解決方案,但是后來發(fā)現(xiàn)仍然有很多人還是不會。無奈只能耗時又耗力的調(diào)試。然而就算是我來分析,也只會根據(jù)對應的表現(xiàn)來判斷是否是跨域,因此這一點是很重要的。
ajax請求時,如果存在跨域現(xiàn)象,并且沒有進行解決,會有如下表現(xiàn):(注意,是ajax請求,請不要說為什么http請求可以,而ajax不行,因為ajax是伴隨著跨域的,所以僅僅是http請求ok是不行的)
注意:具體的后端跨域配置請看題綱位置。
第一種現(xiàn)象:No "Access-Control-Allow-Origin" header is present on the requested resource,并且The response had HTTP status code 404出現(xiàn)這種情況的原因如下:
本次ajax請求是“非簡單請求”,所以請求前會發(fā)送一次預檢請求(OPTIONS)
服務器端后臺接口沒有允許OPTIONS請求,導致無法找到對應接口地址
解決方案: 后端允許options請求
第二種現(xiàn)象:No "Access-Control-Allow-Origin" header is present on the requested resource,并且The response had HTTP status code 405這種現(xiàn)象和第一種有區(qū)別,這種情況下,后臺方法允許OPTIONS請求,但是一些配置文件中(如安全配置),阻止了OPTIONS請求,才會導致這個現(xiàn)象
解決方案: 后端關(guān)閉對應的安全配置
第三種現(xiàn)象:No "Access-Control-Allow-Origin" header is present on the requested resource,并且status 200這種現(xiàn)象和第一種和第二種有區(qū)別,這種情況下,服務器端后臺允許OPTIONS請求,并且接口也允許OPTIONS請求,但是頭部匹配時出現(xiàn)不匹配現(xiàn)象
比如origin頭部檢查不匹配,比如少了一些頭部的支持(如常見的X-Requested-With頭部),然后服務端就會將response返回給前端,前端檢測到這個后就觸發(fā)XHR.onerror,導致前端控制臺報錯
解決方案: 后端增加對應的頭部支持
第四種現(xiàn)象:heade contains multiple values "*,*"表現(xiàn)現(xiàn)象是,后臺響應的http頭部信息有兩個Access-Control-Allow-Origin:*
說實話,這種問題出現(xiàn)的主要原因就是進行跨域配置的人不了解原理,導致了重復配置,如:
常見于.net后臺(一般在web.config中配置了一次origin,然后代碼中又手動添加了一次origin(比如代碼手動設置了返回*))
常見于.net后臺(在IIS和項目的webconfig中同時設置Origin:*)
解決方案(一一對應):
建議刪除代碼中手動添加的*,只用項目配置中的即可
建議刪除IIS下的配置*,只用項目配置中的即可
如何解決ajax跨域一般ajax跨域解決就是通過JSONP解決或者CORS解決,如以下:(注意,現(xiàn)在已經(jīng)幾乎不會再使用JSONP了,所以JSONP了解下即可)
JSONP方式解決跨域問題jsonp解決跨域問題是一個比較古老的方案(實際中不推薦使用),這里做簡單介紹(實際項目中如果要使用JSONP,一般會使用JQ等對JSONP進行了封裝的類庫來進行ajax請求)
實現(xiàn)原理JSONP之所以能夠用來解決跨域方案,主要是因為
實現(xiàn)流程JSONP的實現(xiàn)步驟大致如下(參考了來源中的文章)
客戶端網(wǎng)頁網(wǎng)頁通過添加一個
請注意,以上截圖較老,如果配置仍然出問題,可以考慮增加更多的headers允許,比如:
"Access-Control-Allow-Headers":"X-Requested-With,Content-Type,Accept,Origin"
第二步:其它更多配置,如果第一步進行了后,仍然有跨域問題,可能是:
接口中有限制死一些請求類型(比如寫死了POST等),這時候請去除限 制
接口中,重復配置了Origin:*,請去除即可
IIS服務器中,重復配置了Origin:*,請去除即可
代理請求方式解決接口跨域問題注意,由于接口代理是有代價的,所以這個僅是開發(fā)過程中進行的。
與前面的方法不同,前面CORS是后端解決,而這個主要是前端對接口進行代理,也就是:
前端ajax請求的是本地接口
本地接口接收到請求后向?qū)嶋H的接口請求數(shù)據(jù),然后再將信息返回給前端
一般用node.js即可代理
關(guān)于如何實現(xiàn)代理,這里就不重點描述了,方法和多,也不難,基本都是基于node.js的。
搜索關(guān)鍵字node.js,代理請求即可找到一大票的方案。
OPTIONS預檢的優(yōu)化Access-Control-Max-Age:
這個頭部加上后,可以緩存此次請求的秒數(shù)。
在這個時間范圍內(nèi),所有同類型的請求都將不再發(fā)送預檢請求而是直接使用此次返回的頭作為判斷依據(jù)。
非常有用,可以大幅優(yōu)化請求次數(shù)
如何分析ajax跨域上述已經(jīng)介紹了跨域的原理以及如何解決,但實際過程中,發(fā)現(xiàn)仍然有很多人對照著類似的文檔無法解決跨域問題,主要體現(xiàn)在,前端人員不知道什么時候是跨域問題造成的,什么時候不是,因此這里稍微介紹下如何分析一個請求是否跨域:
抓包請求數(shù)據(jù)第一步當然是得知道我們的ajax請求發(fā)送了什么數(shù)據(jù),接收了什么,做到這一步并不難,也不需要fiddler等工具,僅基于Chrome即可
Chrome瀏覽器打開對應發(fā)生ajax的頁面,F12打開Dev Tools
發(fā)送ajax請求
右側(cè)面板->NetWork->XHR,然后找到剛才的ajax請求,點進去
示例一(正常的ajax請求)上述請求是一個正確的請求,為了方便,我把每一個頭域的意思都表明了,我們可以清晰的看到,接口返回的響應頭域中,包括了
Access-Control-Allow-Headers: X-Requested-With,Content-Type,Accept Access-Control-Allow-Methods: Get,Post,Put,OPTIONS Access-Control-Allow-Origin: *
所以瀏覽器接收到響應時,判斷的是正確的請求,自然不會報錯,成功的拿到了響應數(shù)據(jù)。
示例二(跨域錯誤的ajax請求)為了方便,我們?nèi)匀荒蒙厦娴腻e誤表現(xiàn)示例舉例。
這個請求中,接口Allow里面沒有包括OPTIONS,所以請求出現(xiàn)了跨域、
這個請求中,Access-Control-Allow-Origin: *出現(xiàn)了兩次,導致了跨域配置沒有正確配置,出現(xiàn)了錯誤。
更多跨域錯誤基本都是類似的,就是以上三樣沒有滿足(Headers,Allow,Origin),這里不再一一贅述。
示例三(與跨域無關(guān)的ajax請求)當然,也并不是所有的ajax請求錯誤都與跨域有關(guān),所以請不要混淆,比如以下:
比如這個請求,它的跨域配置沒有一點問題,它出錯僅僅是因為request的Accept和response的Content-Type不匹配而已。
更多基本上都是這樣去分析一個ajax請求,通過Chrome就可以知道了發(fā)送了什么數(shù)據(jù),收到了什么數(shù)據(jù),然后再一一比對就知道問題何在了。
寫在最后的話跨域是一個老生常談的話題,網(wǎng)上也有大量跨域的資料,并且有不少精品(比如阮一峰前輩的),但是身為一個前端人員不應該淺嘗而止,故而才有了本文。
漫漫前端路,望與諸君共勉之!
附錄 參考資料瀏覽器同源政策及其規(guī)避方法(阮一峰)
跨域資源共享 CORS 詳解(阮一峰)
本人之前在cnblog上的文章
博客初次發(fā)布2017.03.22于個人博客
http://www.dailichun.com/2017/03/22/ajaxCrossDomainSolution.html
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/92231.html
摘要:目前,所有瀏覽器都支持該功能,瀏覽器不能低于。因此,實現(xiàn)通信的關(guān)鍵是服務器。如果指定的域名在許可范圍內(nèi),服務器返回的響應,會多出頭信息字段也可能多出其他可選字段或者是表示接受任意域名的請求。 實際跨域問題及其解決方案 1.課題:ajax實現(xiàn)跨域訪問 2.背景: 1.畫面服務器:192.168.196.6 → tomcat服務2.js模板服務器:192.168.196.8 → ngi...
摘要:開發(fā)者需要在中設置屬性為跨域是的簡稱這是一種利用瀏覽器漏洞解決跨域的辦法腳本元素可以不受瀏覽器同源策略的限制。 什么是瀏覽器同源策略? 同源是指,域名,協(xié)議,端口號均相同,如圖: showImg(https://segmentfault.com/img/bV9rAO?w=1088&h=394); 注意:localhost和127.0.0.1雖然都指向本機,但也是跨域. 瀏覽器同源策略(...
閱讀 4066·2021-09-27 13:35
閱讀 1182·2021-09-24 09:48
閱讀 2968·2021-09-22 15:42
閱讀 2404·2021-09-22 15:28
閱讀 3211·2019-08-30 15:43
閱讀 2680·2019-08-30 13:52
閱讀 3037·2019-08-29 12:48
閱讀 1541·2019-08-26 13:55