摘要:但是隨著互聯網的發展,同源策略嚴重影響了項目之間的連接尤其是大項目,有幾個域名需要進行溝通的,標準推出了跨來源資源共享。
同源策略相信各位同學已然不陌生了,在這里不做過多闡述,簡單介紹一下就好:
URL | 說明 | 是否允許 |
---|---|---|
http://www.a.com/a.js?/ http://www.a.com/b.js | 同一域名下 | 允許 |
http://www.a.com/lab/a.js / http://www.a.com/script/b.js | 同一域名下不同文件夾 | 允許 |
http://www.a.com:8000/a.js?http://www.a.com/b.js | 同一域名,不同端口 | 不允許 |
http://www.a.com/a.js?https://www.a.com/b.js | 同一域名,不同協議 | 不允許 |
http://www.a.com/a.js?http://70.32.92.74/b.js | 域名和域名對應ip | 不允許 |
http://www.a.com/a.js?http://script.a.com/b.js | 主域相同,子域不同 | 不允許 |
http://www.a.com/a.js?http://a.com/b.js | 同一域名,不同二級域名(同上) | 不允許(cookie這種情況下也不允許訪問) |
http://www.cnblogs.com/a.js?http://www.a.com/b.js | 不同域名 | 不允許 |
以上表格系統的闡述了如何算是跨域。
那么下面我們
今天我們著重講講對抗同源策略的方法:
CORS——Cross-origin resource sharing(跨來源資源共享)
由于HTML 5的概念形成,在原有XHR的基礎上提出了XMLHttpRequest Level2(XHR2),在XHR2中對CORS有了很好的支持。(除了遠古的IE8,IE9這些老古董)
我們先看看看CORS日常是怎么實現跨域的
? ?isset($_POST["name"])??$_POST["name"]?:?"",?? ? ????"gender"?=>?isset($_POST["gender"])??$_POST["gender"]?:?""?? ? );?? ? ?? ? //HTTP_ORIGIN是請求頭中的信息,在瀏覽器中直接展示為Origin ? $origin?=?isset($_SERVER["HTTP_ORIGIN"])??$_SERVER["HTTP_ORIGIN"]?:?"";?? ? //此處是允許跨域的白名單 ? $allow_origin?=?array(?? ? ????"http://www.client.com",?? ? ????"http://www.client2.com"?? ? );?? ? //判斷當前Origin來源是否在白名單內,是的話就允許設置一套三式Header頭讓他跨域?? ? if(in_array($origin,?$allow_origin)){? ? //關鍵點是這里的一套三式? ? ????header("Access-Control-Allow-Origin:".$origin);??//允許的域名 ? ????header("Access-Control-Allow-Methods:POST");??//允許的方法 ? ????header("Access-Control-Allow-Headers:x-requested-with,content-type");??//服務器支持的頭信息 ? }?? ? ?? ? echo?json_encode($ret);?? ? ?>?
關鍵詞在header("Access-Control-Allow-*":) 一套三件,不同如果無法通過這一套三件的洗禮,那么就報類似下面這樣的錯:
XMLHttpRequest cannot load http://b.com. No "Access-Control-Allow-Origin" header is present on the requested resource. Origin "http://a.com" is therefore not allowed access.
這個就是瀏覽器同源策略造成的,如果我們沒有設置Header頭三件套的話("Access-Control-Allow-*":)那么對一切跨域請求操作瀏覽器都是拒絕的~。
但是隨著互聯網的發展,同源策略嚴重影響了項目之間的連接(尤其是大項目,有幾個域名需要進行溝通的),W3C標準推出了“跨來源資源共享——CORS”。
回到前面的那段實例代碼,我們來分析分析 請求-》處理-》返回 一套流程的來龍去脈。
CORS的背后基本思想就是使用自定義的HTTP頭部讓瀏覽器與服務器進行溝通,從而決定請求響應是應該成功還是應該失敗。
當Http請求發起(可以通過更新操作去測試POST,或者用JavaScript請求測試GET)的時候(不分跨不跨域)會類似帶著以下請求頭信息:
Origin:http://www.csdnblog.com
返回頭也會夾帶著類似如下信息:
Access-Control-Allow-Credentials:true Access-Control-Allow-Origin:http://www.csdnblog.com
一來一回的請求決定的請求決定了改請求是否會被瀏覽器通過,如果返回頭中沒有這個頭部,或者有頭部但是源信息不匹配(就是說返回頭%-Allow-Origin中沒有當前請求站點的域名),那么瀏覽器就會幫我們駁回這次請求,同源策略在這里發揮了作用。
通過這一來一回我們不難發現其實瀏覽器判斷是否駁回的標準就是返回頭中是否有 Access-Control-Allow-% 這個信息,并且判斷這個信息是否合法(即這個信息是否是與請求頭中的Origin對應的上),對應的上就通過,對應不上就駁回。
既然搞懂這個我們就可以理解為何通過CORS設置兩三行Header代碼既可以輕松跨域了吧?
服務端代碼設置Header返回頭告訴瀏覽器“誰誰誰是允許訪問我的,你看到這家伙就給我放行吧~“。
所以如果在服務端代碼中設置:
header("Access-Control-Allow-Origin:*")
是的,這樣的話任何域名都可以請求你的服務器了,當然這樣子你的服務器也就非常危險了。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/11213.html
摘要:關于,強烈推薦閱讀跨域資源共享詳解阮一峰另外,這里也整理了一個實現原理圖簡化版如何判斷是否是簡單請求瀏覽器將請求分成兩類簡單請求和非簡單請求。 前言 從剛接觸前端開發起,跨域這個詞就一直以很高的頻率在身邊重復出現,一直到現在,已經調試過N個跨域相關的問題了,16年時也整理過一篇相關文章,但是感覺還是差了點什么,于是現在重新梳理了一下。 個人見識有限,如有差錯,請多多見諒,歡迎提出iss...
摘要:在接觸前端開發起,跨域這個詞就一直以很高的頻率在我們學習工作中重復出現,最近在工作中遇到了跨域的相關問題,這里我把它總結記錄一下。 在接觸前端開發起,跨域這個詞就一直以很高的頻率在我們學習工作中重復出現,最近在工作中遇到了跨域的相關問題,這里我把它總結記錄一下。關于跨域,有N種類型,現在我只專注于ajax請求跨域(ajax跨域只是屬于瀏覽器同源策略中的一部分,其它的這里不做介紹),內容...
閱讀 3162·2023-04-25 17:19
閱讀 616·2021-11-23 09:51
閱讀 1339·2021-11-08 13:19
閱讀 776·2021-09-29 09:34
閱讀 1673·2021-09-28 09:36
閱讀 1494·2021-09-22 14:59
閱讀 2708·2019-08-29 16:38
閱讀 2053·2019-08-26 13:40