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