這些iframe跨域解決方案你需要了解一下，以后不應該再是你的盲區(qū)

天我們聊一下前端中非常基礎的一個知識點——iframe跨域。

作為一名前端，在業(yè)務中你可能會遇到這樣一個場景：自己開發(fā)的頁面中需要通過iframe嵌入別人的頁面，比如passport頁面（登錄），但是常常因為跨域問題，導致父子頁面無法通信，這時我們就要想辦法如何在跨域的情況下解決這個問題。

什么是跨域？協(xié)議、域名、端口三者中只要有一個不一樣就是跨域！

假設我們有以下場景：

父頁面a通過iframe內嵌子頁面b，兩頁面之間想互相獲取dom等信息，該怎么辦？

a頁面地址：http://jerry.demo.com:8999/a.html
b頁面地址：http://channel.demo.com:9999/b.html

圖1

圖2

圖3

如果父子頁面直接操作對方，就會產生圖3中的跨域報錯！

document.domain

如果只是主域名不同，其他都相同，就可以采用這種方式。比如以上場景的情況，可以設置

document.domain = 'demo.com'；

location.hash

利用頁面url的hash值解決。

a父頁面可以將信息放到子頁面url的hash值中，然后在子頁面的內部監(jiān)聽hash值的變化。

圖4

這種實現方式可以讓子頁面拿到父頁面的信息，但是如何讓父頁面拿到子頁面的信息呢？

b頁面改變a頁面地址hash值，a頁面監(jiān)聽地址欄的變化獲取相應的數據，但是a、b頁面不同源，b頁面不能直接操作改變a頁面地址的hash值。

于是b可以通過創(chuàng)建c頁面（圖6所示），讓c和a同源，把值傳給c，c來改變a的地址hash（圖7所示），從而達到a、b的通信。

圖5

圖6

圖7

window.name

window.name是個特殊的值，無論是iframe內嵌的頁面還是普通的頁面都存在這個變量。它有一個神器的特點就是只要設置了這個值之后無論如何修改頁面的地址（哪怕是跨域的地址），這個值都會一直存在。（跟著頁面窗口存在而不是跟著地址存在）

父到子通信：

圖8

在a頁面中先插入c，a和c同源，所以可以先在a頁面中操作c頁面的window.name，然后再把iframe的src指向b頁面，b和c處于一個iframe窗口，這時window.name的值就可以在b頁面中獲取到！

子到父通信：

圖9

過程正好反過來，先插入b，b頁面中修改window.name，然后再把iframe頁面替換成c，因為a和c同源，所以a頁面就能拿到window.name的值。

此處比較尷尬的是需要隱藏iframe。

window.postMessage

HTML5引入了跨文檔通信 API，使用targetWidw.postMessage發(fā)送消息，window.onmessage監(jiān)聽接收消息。

圖10

圖11

使用時，這個API的兼容性需要考慮一下。

圖12

總結

iframe跨域的場景還是非常多的，在整個前端的職業(yè)生涯中肯定會遇到！如果不了解以上解決問題的手段，遇到這類問題就會很惱人，希望看完這篇文章的讀者都能完全掌握。

喜歡我的文章就關注我吧，有問題可以發(fā)表評論，我們一起學習，共同成長！

先，說明一下window.name這個屬性，我們要用這個屬性來保存從服務器返回的數據。

window.name的值在同一瀏覽器窗口加載不同的頁面后依然存在。（比如在同一瀏覽器窗口下，先訪問頁面a.html，將window.name設定為”Hello World”，然后再訪問b.html，window.name仍然是”Hello World”。）
window.name最多可以支持2MB的值。

接下來結合代碼來說明這個解決方案。為了實現跨域訪問，當然要找到兩個不同的域，最簡單的，用http://localhost/和http://127.0.0.1/就可以了。新建一個client.html并假定其在http://localhost/這個域下面，用來向http://127.0.0.1/域下的頁面server.html發(fā)送異步請求。下面是發(fā)送請求的代碼：

以下是代碼片段：

var iframe1 = document.createElement("iframe");

iframe1.src = "http://127.0.0.1/server.html";

(function() {

// 當iframe加載完之后觸發(fā)的函數

function iframe1_load() {

}

// 在IE下要用attachEvent來添加iframe的onload事件

if(iframe1.attachEvent) {

iframe1.attachEvent("onload", function(){

iframe1_load();

});

}

else {

iframe1.onload = iframe1_load;

}

})();

document.body.appendChild(iframe1);

注意這里的iframe1_load函數，它在iframe1完全加載完之后被瀏覽器調用，我們在這里取回從服務器返回的數據。上面說過，從服務器返回的數據應該是保存在window.name里的，改寫一下iframe1_load：

以下是代碼片段：

function iframe1_load() {

alert(iframe1.contentWindow.name);

}

但由于同源策略的原因，上面的語句會報錯，因為iframe1訪問的頁面在http://127.0.0.1/這個域，而這上面的JavaScript所在的頁面是在http://localhost/，所以client.html暫時還不能訪問iframe1的大部分屬性。這個時候聰明的同學就能想到，如果把iframe1導航到http://localhost/下面的頁面不就可以訪問window.name了嗎？而且上面也說過window.name在換了頁面之后，還是存在的。

根據上面的分析，在http://localhost/下建一個新的頁面empty.html（不用往里添加代碼，只要保證不404就好。），在iframe1_load函數中先把iframe1導航到http://localhost/empty.html，然后再從iframe1的window.name里取數據。注意，iframe1導航到新頁面之后瀏覽器會再次調用iframe1_load，從而造成死循環(huán)，所以還要加個標記。

以下是代碼片段：

var iframe1 = document.createElement("iframe");

iframe1.style.display = "none";

document.body.appendChild(iframe1);

(function () {

var same_domain = false;

// 當iframe加載完之后觸發(fā)的函數

function iframe1_load() {

if (same_domain) {

// 取得從服務器返回的數據

alert(iframe1.contentWindow.name);

// 關閉iframe1的窗口

iframe1.contentWindow.close();

// 移除iframe1

document.body.removeChild(iframe1);

} else {

same_domain = true;

// 不能用iframe1.src = "empty.html"，在IE下有錯誤

iframe1.contentWindow.location = "empty.html";

}

// 在IE下要用attachEvent來添加iframe的onload處理函數

if (iframe1.attachEvent) {

iframe1.attachEvent("onload", function () {

iframe1_load();

});

}

else {

iframe1.onload = iframe1_load;

}

})();

iframe1.src =

http://127.0.0.1/server.html

;

server.html的代碼

以下是代碼片段：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>Server</title>

window.name = "HELLO WORLD";

</script>

</head>

<body>

</body>

</html>

者：寫bug
來源：https://segmentfault.com/a/1190000015597029

引言

跨域這兩個字就像一塊狗皮膏藥一樣黏在每一個前端開發(fā)者身上，無論你在工作上或者面試中無可避免會遇到這個問題。為了應付面試，我每次都隨便背幾個方案，也不知道為什么要這樣干，反正面完就可以扔了，我想工作上也不會用到那么多亂七八糟的方案。

到了真正工作，開發(fā)環(huán)境有webpack-dev-server搞定，上線了服務端的大佬們也會配好，配了什么我不管，反正不會跨域就是了。日子也就這么混過去了，終于有一天，我覺得不能再繼續(xù)這樣混下去了，我一定要徹底搞懂這個東西！于是就有了這篇文章。

要掌握跨域，首先要知道為什么會有跨域這個問題出現

確實，我們這種搬磚工人就是為了混口飯吃嘛，好好的調個接口告訴我跨域了，這種阻礙我們輕松搬磚的事情真惡心！為什么會跨域？是誰在搞事情？為了找到這個問題的始作俑者，請點擊瀏覽器的同源策略[1]。

這么官方的東西真難懂，沒關系，至少你知道了，因為瀏覽器的同源策略導致了跨域，就是瀏覽器在搞事情。

所以，瀏覽器為什么要搞事情？就是不想給好日子我們過？對于這樣的質問，瀏覽器甩鍋道：“同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用于隔離潛在惡意文件的重要安全機制。”

這么官方的話術真難懂，沒關系，至少你知道了，似乎這是個安全機制。所以，究竟為什么需要這樣的安全機制？這樣的安全機制解決了什么問題？別急，讓我們繼續(xù)研究下去。

沒有同源策略限制的兩大危險場景

據我了解，瀏覽器是從兩個方面去做這個同源策略的，一是針對接口的請求，二是針對Dom的查詢。試想一下沒有這樣的限制上述兩種動作有什么危險。

沒有同源策略限制的接口請求

有一個小小的東西叫cookie大家應該知道，一般用來處理登錄等場景，目的是讓服務端知道誰發(fā)出的這次請求。

如果你請求了接口進行登錄，服務端驗證通過后會在響應頭加入Set-Cookie字段，然后下次再發(fā)請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中，服務端就能知道這個用戶已經登錄過了。

知道這個之后，我們來看場景：

1.你準備去清空你的購物車，于是打開了買買買網站www.maimaimai.com，然后登錄成功，一看，購物車東西這么少，不行，還得買多點。

2.你在看有什么東西買的過程中，你的好基友發(fā)給你一個鏈接www.nidongde.com，一臉yin笑地跟你說：“你懂的”，你毫不猶豫打開了。

3.你饒有興致地瀏覽著www.nidongde.com，誰知這個網站暗地里做了些不可描述的事情！由于沒有同源策略的限制，它向www.maimaimai.com發(fā)起了請求！聰明的你一定想到上面的話“服務端驗證通過后會在響應頭加入Set-Cookie字段，然后下次再發(fā)請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中”，這樣一來，這個不法網站就相當于登錄了你的賬號，可以為所欲為了！如果這不是一個買買買賬號，而是你的銀行賬號，那……

這就是傳說中的CSRF攻擊淺談CSRF攻擊方式[2]。

看了這波CSRF攻擊我在想，即使有了同源策略限制，但cookie是明文的，還不是一樣能拿下來。

于是我看了一些cookie相關的文章聊一聊 cookie[3]、Cookie/Session的機制與安全[4]，知道了服務端可以設置httpOnly，使得前端無法操作cookie，如果沒有這樣的設置，像XSS攻擊就可以去獲取到cookieWeb安全測試之XSS[5]；設置secure，則保證在https的加密通信中傳輸以防截獲。

沒有同源策略限制的Dom查詢

1.有一天你剛睡醒，收到一封郵件，說是你的銀行賬號有風險，趕緊點進www.yinghang.com改密碼。你嚇尿了，趕緊點進去，還是熟悉的銀行登錄界面，你果斷輸入你的賬號密碼，登錄進去看看錢有沒有少了。

2.睡眼朦朧的你沒看清楚，平時訪問的銀行網站是www.yinhang.com，而現在訪問的是www.yinghang.com，這個釣魚網站做了什么呢？

// HTML
<iframe name="yinhang" src="www.yinhang.com"></iframe>

// JS
// 由于沒有同源策略的限制，釣魚網站可以直接拿到別的網站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你輸入賬號密碼的Input')
console.log(`拿到了這個 ${node}，我還拿不到你剛剛輸入的賬號密碼嗎`)

由此我們知道，同源策略確實能規(guī)避一些危險，不是說有了同源策略就安全，只是說同源策略是一種瀏覽器最基本的安全機制，畢竟能提高一點攻擊的成本。其實沒有刺不穿的盾，只是攻擊的成本和攻擊成功后獲得的利益成不成正比。

跨域正確的打開方式

經過對同源策略的了解，我們應該要消除對瀏覽器的誤解，同源策略是瀏覽器做的一件好事，是用來防御來自邪門歪道的攻擊，但總不能為了不讓壞人進門而把全部人都拒之門外吧。沒錯，我們這種正人君子只要打開方式正確，就應該可以跨域。

下面將一個個演示正確打開方式，但在此之前，有些準備工作要做。為了本地演示跨域，我們需要：

1.隨便跑起一份前端代碼（以下前端是隨便跑起來的vue），地址是http://localhost:9099。

2.隨便跑起一份后端代碼（以下后端是隨便跑起來的node koa2），地址是http://localhost:9971。

同源策略限制下接口請求的正確打開方式

1.JSONP在HTML標簽里，一些標簽比如script、img這樣的獲取資源的標簽是沒有跨域限制的，利用這一點，我們可以這樣干：

后端寫個小接口

// 處理成功失敗返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async jsonp (ctx) {
    // 前端傳過來的參數
    const query = ctx.request.query
    // 設置一個cookies
    ctx.cookies.set('tokenId', '1')
    // query.cb是前后端約定的方法名字，其實就是后端返回一個直接執(zhí)行的方法給前端，由于前端是用script標簽發(fā)起的請求，所以返回了這個方法后相當于立馬執(zhí)行，并且把要返回的數據放在方法的參數里。
    ctx.body = `${query.cb}(${JSON.stringify(successBody({msg: query.msg}, 'success'))})`
  }
}
module.exports = CrossDomain

簡單版前端

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
  </head>
  <body>
    <script type='text/javascript'>      // 后端返回直接執(zhí)行的方法，相當于執(zhí)行這個方法，由于后端把返回的數據放在方法的參數里，所以這里能拿到res。
      window.jsonpCb = function (res) {
        console.log(res)
      }
    </script>
    <script src='http://localhost:9871/api/jsonp?msg=helloJsonp&cb=jsonpCb' type='text/javascript'></script>
  </body>
</html>

簡單封裝一下前端這個套路

/**
 * JSONP請求工具
 * @param url 請求的地址
 * @param data 請求的參數
 * @returns {Promise<any>}
 */
const request = ({url, data}) => {
  return new Promise((resolve, reject) => {
    // 處理傳參成xx=yy&aa=bb的形式
    const handleData = (data) => {
      const keys = Object.keys(data)
      const keysLen = keys.length
      return keys.reduce((pre, cur, index) => {
        const value = data[cur]
        const flag = index !== keysLen - 1 ? '&' : ''
        return `${pre}${cur}=${value}${flag}`
      }, '')
    }
    // 動態(tài)創(chuàng)建script標簽
    const script = document.createElement('script')
    // 接口返回的數據獲取
    window.jsonpCb = (res) => {
      document.body.removeChild(script)
      delete window.jsonpCb
      resolve(res)
    }
    script.src = `${url}?${handleData(data)}&cb=jsonpCb`
    document.body.appendChild(script)
  })
}
// 使用方式
request({
  url: 'http://localhost:9871/api/jsonp',
  data: {
    // 傳參
    msg: 'helloJsonp'
  }
}).then(res => {
  console.log(res)
})

2.空iframe加form細心的朋友可能發(fā)現，JSONP只能發(fā)GET請求，因為本質上script加載資源就是GET，那么如果要發(fā)POST請求怎么辦呢？

后端寫個小接口

// 處理成功失敗返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async iframePost (ctx) {
    let postData = ctx.request.body
    console.log(postData)
    ctx.body = successBody({postData: postData}, 'success')
  }
}
module.exports = CrossDomain

前端

const requestPost = ({url, data}) => {
  // 首先創(chuàng)建一個用來發(fā)送數據的iframe.
  const iframe = document.createElement('iframe')
  iframe.name = 'iframePost'
  iframe.style.display = 'none'
  document.body.appendChild(iframe)
  const form = document.createElement('form')
  const node = document.createElement('input')
  // 注冊iframe的load事件處理程序,如果你需要在響應返回時執(zhí)行一些操作的話.
  iframe.addEventListener('load', function () {
    console.log('post success')
  })

  form.action = url
  // 在指定的iframe中執(zhí)行form
  form.target = iframe.name
  form.method = 'post'
  for (let name in data) {
    node.name = name
    node.value = data[name].toString()
    form.appendChild(node.cloneNode())
  }
  // 表單元素需要添加到主文檔中.
  form.style.display = 'none'
  document.body.appendChild(form)
  form.submit()

  // 表單提交后,就可以刪除這個表單,不影響下次的數據發(fā)送.
  document.body.removeChild(form)
}
// 使用方式
requestPost({
  url: 'http://localhost:9871/api/iframePost',
  data: {
    msg: 'helloIframePost'
  }
})

3.CORS

CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）跨域資源共享 CORS 詳解[6]。看名字就知道這是處理跨域問題的標準做法。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

1.簡單請求后端

// 處理成功失敗返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // *時cookie不會在http請求中帶上
    ctx.set('Access-Control-Allow-Origin', '*')
    ctx.cookies.set('tokenId', '2')
    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

前端什么也不用干，就是正常發(fā)請求就可以，如果需要帶cookie的話，前后端都要設置一下，下面那個非簡單請求例子會看到。

fetch(`http://localhost:9871/api/cors?msg=helloCors`).then(res => {
  console.log(res)
})

2.非簡單請求非簡單請求會發(fā)出一次預檢測請求，返回碼是204，預檢測通過才會真正發(fā)出請求，這才返回200。這里通過前端發(fā)請求的時候增加一個額外的headers來觸發(fā)非簡單請求。

后端

// 處理成功失敗返回格式的工具
const {successBody} = require('../utli')
class CrossDomain {
  static async cors (ctx) {
    const query = ctx.request.query
    // 如果需要http請求中帶上cookie，需要前后端都設置credentials，且后端設置指定的origin
    ctx.set('Access-Control-Allow-Origin', 'http://localhost:9099')
    ctx.set('Access-Control-Allow-Credentials', true)
    // 非簡單請求的CORS請求，會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight）
    // 這種情況下除了設置origin，還需要設置Access-Control-Request-Method以及Access-Control-Request-Headers
    ctx.set('Access-Control-Request-Method', 'PUT,POST,GET,DELETE,OPTIONS')
    ctx.set('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept, t')
    ctx.cookies.set('tokenId', '2')

    ctx.body = successBody({msg: query.msg}, 'success')
  }
}
module.exports = CrossDomain

一個接口就要寫這么多代碼，如果想所有接口都統(tǒng)一處理，有什么更優(yōu)雅的方式呢？見下面的koa2-cors。

const path = require('path')
const Koa = require('koa')
const koaStatic = require('koa-static')
const bodyParser = require('koa-bodyparser')
const router = require('./router')
const cors = require('koa2-cors')
const app = new Koa()
const port = 9871
app.use(bodyParser())
// 處理靜態(tài)資源 這里是前端build好之后的目錄
app.use(koaStatic(
  path.resolve(__dirname, '../dist')
))
// 處理cors
app.use(cors({
  origin: function (ctx) {
    return 'http://localhost:9099'
  },
  credentials: true,
  allowMethods: ['GET', 'POST', 'DELETE'],
  allowHeaders: ['t', 'Content-Type']
}))
// 路由
app.use(router.routes()).use(router.allowedMethods())
// 監(jiān)聽端口
app.listen(9871)
console.log(`[demo] start-quick is starting at port ${port}`)

前端

fetch(`http://localhost:9871/api/cors?msg=helloCors`, {
  // 需要帶上cookie
  credentials: 'include',
  // 這里添加額外的headers來觸發(fā)非簡單請求
  headers: {
    't': 'extra headers'
  }
}).then(res => {
  console.log(res)
})

4.代理想一下，如果我們請求的時候還是用前端的域名，然后有個東西幫我們把這個請求轉發(fā)到真正的后端域名上，不就避免跨域了嗎？這時候，Nginx出場了。Nginx配置

server{
    # 監(jiān)聽9099端口
    listen 9099;
    # 域名是localhost
    server_name localhost;
    #凡是localhost:9099/api這個樣子的，都轉發(fā)到真正的服務端地址http://localhost:9871 
    location ^~ /api {
        proxy_pass http://localhost:9871;
    }    
}

前端就不用干什么事情了，除了寫接口，也沒后端什么事情了

// 請求的時候直接用回前端這邊的域名http://localhost:9099，這就不會跨域，然后Nginx監(jiān)聽到凡是localhost:9099/api這個樣子的，都轉發(fā)到真正的服務端地址http://localhost:9871 
fetch('http://localhost:9099/api/iframePost', {
  method: 'POST',
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    msg: 'helloIframePost'
  })
})

Nginx轉發(fā)的方式似乎很方便！但這種使用也是看場景的，如果后端接口是一個公共的API，比如一些公共服務獲取天氣什么的，前端調用的時候總不能讓運維去配置一下Nginx，如果兼容性沒問題（IE 10或者以上），CROS才是更通用的做法吧。

同源策略限制下Dom查詢的正確打開方式

1.postMessagewindow.postMessage() 是HTML5的一個接口，專注實現不同窗口不同頁面的跨域通訊。為了演示方便，我們將hosts改一下：127.0.0.1 crossDomain.com，現在訪問域名crossDomain.com就等于訪問127.0.0.1。

這里是http://localhost:9099/#/crossDomain，發(fā)消息方

<template>
  <div>
    <button @click="postMessage">給http://crossDomain.com:9099發(fā)消息</button>
    <iframe name="crossDomainIframe" src="http://crossdomain.com:9099"></iframe>
  </div>
</template>

<script>export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 這里一定要對來源做校驗
      if (e.origin === 'http://crossdomain.com:9099') {
        // 來自http://crossdomain.com:9099的結果回復
        console.log(e.data)
      }
    })
  },
  methods: {
    // 向http://crossdomain.com:9099發(fā)消息
    postMessage () {
      const iframe = window.frames['crossDomainIframe']
      iframe.postMessage('我是[http://localhost:9099], 麻煩你查一下你那邊有沒有id為app的Dom', 'http://crossdomain.com:9099')
    }
  }
}</script>

這里是http://crossdomain.com:9099，接收消息方

<template>
  <div>
    我是http://crossdomain.com:9099
  </div>
</template>

<script>export default {
  mounted () {
    window.addEventListener('message', (e) => {
      // 這里一定要對來源做校驗
      if (e.origin === 'http://localhost:9099') {
        // http://localhost:9099發(fā)來的信息
        console.log(e.data)
        // e.source可以是回信的對象，其實就是http://localhost:9099窗口對象(window)的引用
        // e.origin可以作為targetOrigin
        e.source.postMessage(`我是[http://crossdomain.com:9099]，我知道了兄弟，這就是你想知道的結果：${document.getElementById('app') ? '有id為app的Dom' : '沒有id為app的Dom'}`, e.origin);
      }
    })
  }
}</script>

結果可以看到：

2.document.domain這種方式只適合主域名相同，但子域名不同的iframe跨域。比如主域名是http://crossdomain.com:9099，子域名是http://child.crossdomain.com:9099，這種情況下給兩個頁面指定一下document.domain即document.domain = crossdomain.com就可以訪問各自的window對象了。

3.canvas操作圖片的跨域問題這個應該是一個比較冷門的跨域問題，張大神已經寫過了我就不再班門弄斧了解決canvas圖片getImageData,toDataURL跨域問題[7]

最后

希望看完這篇文章之后，再有人問跨域的問題，你可以嘴角微微上揚，冷笑一聲：“不要再問我跨域的問題了。” 揚長而去。

如果學到了可以點在看讓更多的小伙伴看到哦。

參考資料
[1]瀏覽器的同源策略: https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
[2]淺談CSRF攻擊方式: http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
[3]聊一聊 cookie: https://segmentfault.com/a/1190000004556040#articleHeader6
[4]Cookie/Session的機制與安全: https://harttle.land/2015/08/10/cookie-session.html
[5]Web安全測試之XSS: https://www.cnblogs.com/TankXiao/archive/2012/03/21/2337194.html
[6]跨域資源共享 CORS 詳解: http://www.ruanyifeng.com/blog/2016/04/cors.html
[7]解決canvas圖片getImageData,toDataURL跨域問題: https://www.zhangxinxu.com/wordpress/2018/02/crossorigin-canvas-getimagedata-cors/

在線咨詢

上一篇：WEB前端-CSS盒子
下一篇：JavaScript 表格隔行變色

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

這些iframe跨域解決方案你需要了解一下，以后不應該再是你的盲區(qū)

document.domain

location.hash

window.name

window.postMessage

總結

引言

要掌握跨域，首先要知道為什么會有跨域這個問題出現

沒有同源策略限制的兩大危險場景

沒有同源策略限制的接口請求

沒有同源策略限制的Dom查詢

跨域正確的打開方式

同源策略限制下接口請求的正確打開方式

同源策略限制下Dom查詢的正確打開方式

最后

您的項目需求