同源策略及跨域問(wèn)題

同源策略是一套瀏覽器安全機(jī)制孔飒，當(dāng)一個(gè)源的文檔和腳本寄悯，與另一個(gè)源的資源進(jìn)行通信時(shí)萤衰，同源策略就會(huì)對(duì)這個(gè)通信做出不同程度的限制。

簡(jiǎn)單來(lái)說(shuō)猜旬，同源策略對(duì) 同源資源 放行脆栋，對(duì) 異源資源 限制

因此限制造成的開發(fā)問(wèn)題胳螟，稱之為跨域（異源）問(wèn)題

同源和異源

源(origin) = 協(xié)議 + 域名 + 端口

例如:

https://study.duyiedu.com/api/movie的源為https://study.duyiedu.com

http://localhost:7001/index.html的源為http://localhost:7001

兩個(gè)URL地址的源完全相同，則稱之為同源筹吐，否則稱之為異源（跨域）

20210927145456.png

跨域出現(xiàn)的場(chǎng)景

跨域可能出現(xiàn)在三種場(chǎng)景：

• 網(wǎng)絡(luò)通信

  a元素的跳轉(zhuǎn)糖耸；加載css、js丘薛、圖片等嘉竟；AJAX等等

• JS API

  window.open、window.parent洋侨、iframe.contentWindow等等

• 存儲(chǔ)

  WebStorage舍扰、IndexedDB等等

對(duì)于不同的跨域場(chǎng)景，以及每個(gè)場(chǎng)景中不同的跨域方式希坚，同源策略都有不同的限制边苹。

本文重點(diǎn)討論網(wǎng)絡(luò)通信中AJAX的跨域問(wèn)題

網(wǎng)絡(luò)中的跨域

當(dāng)瀏覽器運(yùn)行頁(yè)面后，會(huì)發(fā)出很多的網(wǎng)絡(luò)請(qǐng)求裁僧，例如CSS个束、JS、圖片聊疲、AJAX等等

請(qǐng)求頁(yè)面的源稱之為頁(yè)面源茬底，在該頁(yè)面中發(fā)出的請(qǐng)求稱之為目標(biāo)源。

當(dāng)頁(yè)面源和目標(biāo)源一致時(shí)获洲，則為同源請(qǐng)求阱表，否則為異源請(qǐng)求（跨域請(qǐng)求）

20210927145456.png

瀏覽器如何限制異源請(qǐng)求？

瀏覽器出于多方面的考量贡珊，制定了非常繁雜的規(guī)則來(lái)限制各種跨域請(qǐng)求最爬，但總體的原則非常簡(jiǎn)單：

• 對(duì)標(biāo)簽發(fā)出的跨域請(qǐng)求輕微限制
• 對(duì)AJAX發(fā)出的跨域請(qǐng)求嚴(yán)厲限制

20210927145456.png

解決方案

CORS

CORS（Cross-Origin Resource Sharing）是最正統(tǒng)的跨域解決方案，同時(shí)也是瀏覽器推薦的解決方案门岔。

CORS是一套規(guī)則爱致，用于幫助瀏覽器判斷是否校驗(yàn)通過(guò)。

20210927145456.png

CORS的基本理念是：

• 只要服務(wù)器明確表示允許固歪，則校驗(yàn)通過(guò)
• 服務(wù)器明確拒絕或沒(méi)有表示蒜鸡，則校驗(yàn)不通過(guò)

所以胯努，使用CORS解決跨域牢裳，必須要保證服務(wù)器是「自己人」

請(qǐng)求分類

CORS將請(qǐng)求分為兩類：==簡(jiǎn)單請(qǐng)求==和==預(yù)檢請(qǐng)求==。

對(duì)不同種類的請(qǐng)求它的規(guī)則有所區(qū)別叶沛。

所以要理解CORS蒲讯，首先要理解它是如何劃分請(qǐng)求的。

簡(jiǎn)單請(qǐng)求

完整判定邏輯：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests

簡(jiǎn)單來(lái)說(shuō)灰署，只要全部滿足下列條件判帮，就是簡(jiǎn)單請(qǐng)求：

• 請(qǐng)求方法是GET局嘁、POST、HEAD之一

• 頭部字段滿足CORS安全規(guī)范晦墙，詳見 W3C

  瀏覽器默認(rèn)自帶的頭部字段都是滿足安全規(guī)范的悦昵，只要開發(fā)者不改動(dòng)和新增頭部，就不會(huì)打破此條規(guī)則

• 如果有Content-Type晌畅，必須是下列值中的一個(gè)

  • text/plain
  • multipart/form-data
  • application/x-www-form-urlencoded

預(yù)檢請(qǐng)求(preflight)

只要不是簡(jiǎn)單請(qǐng)求但指，均為預(yù)檢請(qǐng)求

練習(xí)

// 下面的跨域請(qǐng)求哪些是簡(jiǎn)單請(qǐng)求，哪些是預(yù)檢請(qǐng)求

// 1 簡(jiǎn)單
fetch('https://douyin.com');

// 2 預(yù)檢 動(dòng)了header
fetch('https://douyin.com', {
  headers: {
    a: 1,
  },
});

// 3 簡(jiǎn)單
fetch('https://douyin.com', {
  method: 'POST',
  body: JSON.stringify({ a: 1, b: 2 }),
});

// 4 預(yù)檢 content-type 不滿足
fetch('https://douyin.com', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
  },
  body: JSON.stringify({ a: 1, b: 2 }),
});

對(duì)簡(jiǎn)單請(qǐng)求的驗(yàn)證

20210927145456.png

對(duì)預(yù)檢請(qǐng)求的驗(yàn)證

1. 發(fā)送預(yù)檢請(qǐng)求

20210927145456.png

2. 發(fā)送真實(shí)請(qǐng)求（和簡(jiǎn)單請(qǐng)求一致）

細(xì)節(jié)1 - 關(guān)于cookie

默認(rèn)情況下抗楔，ajax的跨域請(qǐng)求并不會(huì)附帶cookie棋凳，這樣一來(lái)，某些需要權(quán)限的操作就無(wú)法進(jìn)行

不過(guò)可以通過(guò)簡(jiǎn)單的配置就可以實(shí)現(xiàn)附帶cookie

// xhr
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

// fetch api
fetch(url, {
  credentials: "include"
})

這樣一來(lái)连躏，該跨域的ajax請(qǐng)求就是一個(gè)附帶身份憑證的請(qǐng)求

當(dāng)一個(gè)請(qǐng)求需要附帶cookie時(shí)剩岳，無(wú)論它是簡(jiǎn)單請(qǐng)求，還是預(yù)檢請(qǐng)求入热，都會(huì)在請(qǐng)求頭中添加cookie字段

而服務(wù)器響應(yīng)時(shí)拍棕，需要明確告知客戶端：服務(wù)器允許這樣的憑據(jù)

告知的方式也非常的簡(jiǎn)單，只需要在響應(yīng)頭中添加：Access-Control-Allow-Credentials: true即可

對(duì)于一個(gè)附帶身份憑證的請(qǐng)求勺良，若服務(wù)器沒(méi)有明確告知莫湘，瀏覽器仍然視為跨域被拒絕。

另外要特別注意的是：對(duì)于附帶身份憑證的請(qǐng)求郑气，服務(wù)器不得設(shè)置 Access-Control-Allow-Origin 的值為*幅垮。這就是為什么不推薦使用*的原因

細(xì)節(jié)2 - 關(guān)于跨域獲取響應(yīng)頭

在跨域訪問(wèn)時(shí)，JS只能拿到一些最基本的響應(yīng)頭尾组，如：Cache-Control忙芒、Content-Language、Content-Type讳侨、Expires呵萨、Last-Modified、Pragma跨跨，如果要訪問(wèn)其他頭潮峦，則需要服務(wù)器設(shè)置本響應(yīng)頭。

Access-Control-Expose-Headers頭讓服務(wù)器把允許瀏覽器訪問(wèn)的頭放入白名單勇婴，例如：

Access-Control-Expose-Headers: authorization, a, b

這樣JS就能夠訪問(wèn)指定的響應(yīng)頭了忱嘹。

JSONP

在很久很久以前...并沒(méi)有CORS方案

20210927145456.png

在那個(gè)年代，古人靠著非凡的智慧來(lái)解決這一問(wèn)題

20210927145456.png

雖然可以解決問(wèn)題耕渴，但JSONP有著明顯的缺陷：

• 僅能使用GET請(qǐng)求

• 容易產(chǎn)生安全隱患

  惡意攻擊者可能利用callback=惡意函數(shù)的方式實(shí)現(xiàn)XSS攻擊

• 容易被非法站點(diǎn)惡意調(diào)用

因此拘悦，除非是某些特殊的原因，否則永遠(yuǎn)不應(yīng)該使用JSONP

代理

CORS和JSONP均要求服務(wù)器是「自己人」

那如果不是呢橱脸？

20210927145456.png

那就找一個(gè)中間人（代理）

20210927145456.png

比如础米，前端小王想要請(qǐng)求獲取王者榮耀英雄數(shù)據(jù)分苇，但直接請(qǐng)求騰訊服務(wù)器會(huì)造成跨域

20210927145456.png

由于騰訊服務(wù)器不是「自己人」，小王決定用代理解決

20210927145456.png

如何選擇

最重要的屁桑，是要保持生產(chǎn)環(huán)境和開發(fā)環(huán)境一致

下面是一張決策圖

20210927145456.png

具體的幾種場(chǎng)景

20210927145456.png

20210927145456.png