同源策略與JS跨域

爲何要跨域

爲了用戶的信息安全，瀏覽器就引入了同源策略
那麼同源策略是如何保證用戶的信息安全的呢？

• 若是沒有同源策略，你打開了你的銀行帳戶頁面A，又打開了另外一個不相關的頁面B，這時候若是B是惡意網站，B能夠經過Javascript輕鬆訪問和修改A頁面中的內容
• 如今咱們普遍的使用cookie來維護用戶的登陸狀態，而若是沒有同源策略，這些cookie信息就會泄露，其餘網站就能夠冒充這個登陸用戶

由此能夠看出，同源策略確實是必不可少的，那麼它會帶來哪些限制呢？

1. Cookie、LocalStorage和IndexDB沒法讀取
2. DOM沒法得到
3. AJAX請求不能發送

有時候咱們須要突破上述限制，就須要用跨域的方法來解決

跨域是什麼？

1. 什麼叫作不一樣的域？
   協議（http）、域名（www.a.com）、端口（8000）三者中有一個不一樣就叫不一樣的域
2. 跨域就是不一樣的域間相互訪問時使用某些方法來突破上述限制
3. 協議或者端口的不一樣，只能經過後臺來解決

如何實現跨域？

1、解決上面提到的一、2兩點限制：

1. 經過document.domain跨子域

適用範圍：

1. 兩個域只是子域不一樣
2. 只適用於iframe窗口與父窗口之間互相獲取cookie和DOM節點，不能突破LocalStorage和IndexDB的限制

當兩個不一樣的域只是子域不一樣時，能夠經過把document.domain設置爲他們共同的父域來解決

eg:
A: http://www.example.com/a.html
B: http://example.com/b.html

當A、B想要獲取對方的cookie或者DOM節點時，能夠設置:

document.domain=‘example.com’;

這時A網頁經過腳本設置:

document.cookie = 「testA=hello」;

B網頁就能夠拿到這個cookie：

var aCookie = document.cookie;

2. 經過window.name跨域

使用範圍：

1. 能夠是兩個徹底不一樣源的域
2. 同一個窗口內：即同一個標籤頁內前後打開的窗口

window.name屬性有個特徵：即在一個窗口(window)的生命週期內,窗口載入的全部的頁面都是共享一個window.name的，每一個頁面對window.name都有讀寫的權限，window.name是持久存在一個窗口載入過的全部頁面中的。

基於這個思想，咱們能夠在某個頁面設置好 window.name 的值，而後在本標籤頁內跳轉到另一個域下的頁面。在這個頁面中就能夠獲取到咱們剛剛設置的 window.name 了。

結合iframe還有更高級的用法：

父窗口先打開一個與本身不一樣源的子窗口，在這個子窗口裏設置：

window.name = data;

而後讓子窗口跳轉到一個與父窗口同域的網址：

location=‘http://www.parent.com/a.html’;

這時，由於同域而且同一窗口window.name是不變的，因此父窗口能夠獲取到子窗口下的window.name。

var data = document.getElementById(‘myFrame’).contentWindow.name;

優勢：window.name容量很大，能夠放置很是長的字符串；缺點：必須監聽子窗口window.name屬性的變化，影響網頁性能。

3. 使用HTML5的window.postMessage跨域

window.postMessage(message,targetOrigin) 方法是html5新引進的特性，可使用它來向其它的window對象發送消息，不管這個window對象是屬於同源或不一樣源，目前IE8+、FireFox、Chrome、Opera等瀏覽器都已經支持window.postMessage方法。

otherWindow.postMessage(message, targetOrigin);

otherWindow:接受消息頁面的window的引用。能夠是頁面中iframe的contentWindow屬性；window.open的返回值；經過name或下標從window.frames取到的值。
message:所要發送的數據，string類型。
targetOrigin:用於限制otherWindow，*表示不作限制。

eg1:

在父頁面中嵌入子頁面，經過postMessage發送數據。
parent.com/index.html中的代碼：

<iframe id="ifr" src="child.com/index.html"></iframe>
<script type="text/javascript">
window.onload = function() {
    var ifr = document.getElementById('ifr');
    var targetOrigin = 'http://child.com'; 
    // 若寫成'http://child.com/c/proxy.html'效果同樣
    // 若寫成'http://c.com'就不會執行postMessage了
    ifr.contentWindow.postMessage('I was there!', targetOrigin);
};
</script>

在子頁面中經過message事件監聽父頁面發送來的消息並顯示。
child.com/index.html中的代碼：

<script type="text/javascript">
window.addEventListener('message', function(event){
    // 經過origin屬性判斷消息來源地址
    if (event.origin == 'http://parent.com') {
        alert(event.data);    // 彈出"I was there!"
        alert(event.source);  
        // 對parent.com、index.html中window對象的引用
        // 但因爲同源策略，這裏event.source不能夠訪問window對象
    }
}, false);
</script>

eg2:

假設在a.html裏嵌套個

<iframe src="http://www.child.com/b.html" frameborder="0"></iframe>

在這兩個頁面裏互相通訊

a.html

window.onload = function() {
    window.addEventListener("message", function(e) {
        alert(e.data);
    });

    window.frames[0].postMessage("b data", "http://www.child.com/b.html");
}

b.html

window.onload = function() {
    window.addEventListener("message", function(e) {
        alert(e.data);
    });
    window.parent.postMessage("a data", "http://www.parent.com/a.html");
}

這樣打開a頁面，首先監聽到了b.html經過postMessage傳來的消息，就先彈出 a data，而後a經過postMessage傳遞消息給子頁面b.html，這時會彈出 b data

2、解決第3點限制：

AJAX請求不能發送

4. 經過JSONP跨域

適用範圍：

1. 能夠是兩個徹底不一樣源的域；
2. 只支持HTTP請求中的GET方式；
3. 老式瀏覽器所有支持；
4. 須要服務端支持

JSONP(JSON with Padding)是資料格式JSON的一種使用模式，可讓網頁從別的網域要資料。

因爲瀏覽器的同源策略，在網頁端出現了這個「跨域」的問題，然而咱們發現，全部的 src 屬性並無受到相關的限制，好比 img / script 等。

JSONP 的原理就要從 script 提及。script 能夠引用其餘域的腳本文件，好比這樣：

a.html
...
<script>
    function callback(data) {
        console.log(data.url)
    }
</script>
<script src='b.js'></script>
...

b.js
callback({url: 'http://www.rccoder.net'})

這就相似於JSONP的原理了。

JSONP的基本思想是：先在網頁上添加一個script標籤，設置這個script標籤的src屬性用於向服務器請求JSON數據 ，須要注意的是，src屬性的查詢字符串必定要加一個callback參數，用來指定回調函數的名字 。而這個函數是在資源加載以前就已經在前端定義好的，這個函數接受一個參數並利用這個參數作一些事情。向服務器請求後，服務器會將JSON數據放在一個指定名字的回調函數裏做爲其參數傳回來。這時，由於函數已經在前端定義好了，因此會直接調用。

eg：

function addScriptTag(src) {
    var script = document.createElement('script');
    script.setAttribute("type","text/javascript");
    script.src = src;
    document.body.appendChild(script);
}

window.onload = function () {
    addScriptTag('http://example.com/ip?callback=foo');//請求服務器數據並規定回調函數爲foo
}

function foo(data) {
    console.log('Your public IP address is: ' + data.ip);
};

向服務器example.com請求數據，這時服務器會先生成JSON數據，這裏是{「ip」: 「8.8.8.8」}，而後以JS語法的方式生成一個函數，函數名就是傳遞上來的callback參數的值，最後將數據放在函數的參數中返回：

foo({
    "ip": "8.8.8.8"
});

客戶端解析script標籤，執行返回的JS代碼，調用函數。

5. 經過CORS跨域

適用範圍：

1. 能夠是兩個徹底不一樣源的域；
2. 支持全部類型的HTTP請求；
3. 被絕大多數現代瀏覽器支持，老式瀏覽器不支持；
4. 須要服務端支持

對於前端開發者來講，跨域的CORS通訊與同源的AJAX通訊沒有差異，代碼徹底同樣。所以，實現CORS通訊的關鍵是服務器。只要服務器實現了CORS接口，就能夠跨源通訊。

瀏覽器將CORS請求分紅兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。

只要同時知足如下兩大條件，就屬於簡單請求。

（1) 請求方法是如下三種方法之一：
HEAD
GET
POST
（2）HTTP的頭信息不超出如下幾種字段：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不一樣時知足上面兩個條件，就屬於非簡單請求。
瀏覽器對這兩種請求的處理，是不同的。

簡單請求：
下面是一次跨源AJAX請求，瀏覽器發現它是簡單請求，就會直接在頭信息中加一個origin字段：

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

服務器收到這條請求，若是這個origin指定的源在許可範圍內，那麼服務器返回的頭信息中會包含Access-Control-Allow-Origin字段，值與origin的值相同，以及其餘幾個相關字段：

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar

Access-Control-Allow-Origin: 該字段是必須的。要麼與origin相同，要麼爲*
Access-Control-Allow-Credentials: 該字段可選。設爲true表示服務器容許發送cookie
Access-Control-Expose-Headers: 該字段可選。CORS請求時，XMLHttpRequest對象的getResponseHeader()方法只能拿到6個基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。若是想拿到其餘字段，就必須在Access-Control-Expose-Headers裏面指定。上面的例子指定，getResponseHeader(‘FooBar’)能夠返回FooBar字段的值。

想要發送cookie，這裏還有兩點須要額外注意：

1）開發者必須在AJAX請求中打開withCredentials屬性。

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

不然即便服務器容許，客戶端也不會發送。

2）Access-Control-Allow-Origin不能設爲星號，必須指定明確的、與請求網頁一致的域名。同時，Cookie依然遵循同源政策，只有用服務器域名設置的Cookie纔會上傳，其餘域名的Cookie並不會上傳，且（跨源）原網頁代碼中的document.cookie也沒法讀取服務器域名下的Cookie。

非簡單請求：
1.預檢請求：

非簡單請求會在正式通訊前加一次預檢（preflight）請求。做用是瀏覽器先詢問服務器當前網頁所在域名是否在服務器的許可名單中，以及可使用哪些HTTP方法以及頭信息字段。只有獲得確定答覆，瀏覽器纔會發送XMLHttpRequest，不然報錯。
一個例子：

var url = 'http://api.alice.com/cors';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

HTTP請求方法爲PUT，併發送一個自定義頭信息"X-Custom-Header"，瀏覽器發現這是一個非簡單請求，就會自動發送一個預檢請求，預檢請求的HTTP頭信息以下：

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

請求方法是OPTIONS，表示這個請求是用來詢問的，頭信息中的關鍵信息有3個：

（1）表示請求來自哪一個源

Origin: http://api.bob.com

（2）列出瀏覽器的CORS請求會用到哪些HTTP方法

Access-Control-Request-Method: PUT

（3）指定瀏覽器CORS請求會額外發送的頭信息字段

Access-Control-Request-Headers: X-Custom-Header

2.預檢請求的迴應（有兩種狀況：A容許、B不容許）

A.服務器容許此次跨域請求

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

服務器返回中要注意的字段：

（1）服務器贊成的跨域請求源：

Access-Control-Allow-Origin: http://api.bob.com

（2）服務器支持的全部跨域請求的方法：

Access-Control-Allow-Methods: GET, POST, PUT

（3）代表服務器支持的全部頭信息字段：

Access-Control-Allow-Headers: X-Custom-Header

（4）指定本次預檢請求的有效期，單位爲秒，即容許請求該條迴應在有效期以前都不用再發送預檢請求：

Access-Control-Max-Age: 1728000

B.服務器不容許此次跨域請求
即origin指定的源不在許可範圍內，服務器會返回一個正常的HTTP迴應。可是頭信息中沒有包含Access-Control-Allow-Origin字段，就知道出錯了，從而拋出一個錯誤，被XMLHttpRequest的onerror回調函數捕獲。可是要注意的是，這種HTTP迴應的狀態碼頗有多是200，因此沒法經過狀態碼識別這種錯誤。

3.正式請求 過了預檢請求，非簡單請求的正式請求就與簡單請求同樣了。