九种跨域方式实现原理

序言

其间端统计数据可视化时常会遇到允诺布吕马，甚么是布吕马，和有这三类布吕马形式，这是责任编辑要深入探讨的文本。

责任编辑完备的源码请猛戳github网志

一、甚么是布吕马？ 1.甚么是相混思路或其管制文本？

相混思路是一类签订合同，它是应用程序最核心理念也最基本上的安全可靠机能，假如缺乏了相混思路，应用程序很难受XSS、CSRF等反击。简而言之相混是指”协定+搜索引擎+路由器”二者完全相同，即使三个相同的搜索引擎对准同一ip门牌号，也非相混。相混思路管制文本有：

Cookie、LocalStorage、IndexedDB 等储存性文本

DOM 结点

AJAX 允诺推送后，结论被应用程序截击了

但有四个条码是容许布吕马读取天然资源：

当协定、子搜索引擎、主搜索引擎、路由器号中任一两个不完全相同时，都算是相同域。相同域间互相允诺天然资源，即使是“布吕马”。常用布吕马情景如下表所示图右图：

不光表明三点：

第三：假如是协定和路由器导致的布吕马难题“后台”是束手无策的。

第三：在布吕马难题上，实际上是透过“URL的第三部”来辨识而不能依照搜索引擎相关联的IP门牌号与否完全相同来推论。“URL的第三部”能认知为“协定, 搜索引擎和路由器要相匹配”。

这里你或许有个疑问：允诺布吕马了，那么允诺到底发出去没有？

布吕马并不是允诺发不出去，允诺能发出去，服务端能收到允诺并正常返回结论，只是结论被应用程序截击了。你可能会疑问明明透过表单的形式能发起布吕马允诺，为甚么 Ajax 就不能?因为归根结底，布吕马是为了阻止用户读取到另

二、跨域解决方案 1.jsonp 1) JSONP基本上原理

利用

// b.html

window.onmessage = function(e) {

console.log(e.data) //我爱你

e.source.postMessage(我不爱你, e.origin)

}

Websocket是HTML5的两个持久化的协定，它同时实现了应用程序与服务器的全双工通信，同时也是布吕马的一类解决方案。WebSocket和HTTP都是应用层协定，都基于 TCP 协定。但WebSocket 是一类双向通信协定，在建立连接之后，WebSocket 的 server 与 client 都能主动向对方推送或接收统计数据。同时，WebSocket 在建立连接时需要借助 HTTP 协定，连接建立好了之后 client 与 server 间的双向通信就与 HTTP 无关了。

原生WebSocket API使用起来不太方便，我们使用Socket.io，它很好地封装了webSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的应用程序提供了向下兼容。

我们先来看个例子：本地文件socket.html向localhost:3000发生统计数据和接受统计数据

// socket.html

// server.js

let express = require(express);

let app = express();

letWebSocket= require(ws);//记得安装ws

let wss = newWebSocket.Server({port:3000});

wss.on(connection,function(ws) {

ws.on(message, function(data) {

console.log(data);

ws.send(我不爱你)

});

})

同时实现基本上原理：同源思路是应用程序需要遵循的标准，而假如是服务器向服务器允诺就无需遵循相混思路。代理服务器，需要做以下几个步骤：

接受客户端允诺 。

将允诺 转发给服务器。

拿到服务器 响应 统计数据。

将 响应 转发给客户端。

我们先来看个例子：本地文件index.html文件，透过代理服务器http://localhost:3000向目标服务器http://localhost:4000允诺统计数据。

// index.html(http://127.0.0.1:5500)

// server1.js 代理服务器(http://localhost:3000)

const http = require(http)

// 第三步：接受客户端允诺

const server = http.createServer((request, response) => {

// 代理服务器，直接和应用程序直接可视化，需要设置CORS 的第三部字段

response.writeHead(200, {

Access-Control-Allow-Origin: *,

Access-Control-Allow-Methods: *,

Access-Control-Allow-Headers: Content-Type

})

// 第三步：将允诺转发给服务器

const proxyRequest = http

.request(

{

host: 127.0.0.1,

port: 4000,

url: /,

method: request.method,

headers: request.headers

},

serverResponse => {

// 第三步：收到服务器的响应

var body =

serverResponse.on(data, chunk => {

body += chunk

})

serverResponse.on(end, () => {

console.log(The data is + body)

// 第四步：将响应结论转发给应用程序

response.end(body)

})

}

)

.end()

})

server.listen(3000, () => {

console.log(The proxyServer is running at http://localhost:3000)

})

// server2.js(http://localhost:4000)

const http = require(http)

const data = { title: fontend, password: 123456}

const server = http.createServer((request, response) => {

if(request.url === /) {

response.end(JSON.stringify(data))

}

})

server.listen(4000, () => {

console.log(The server is running at http://localhost:4000)

})

上述代码经过两次布吕马，值得注意的是应用程序向代理服务器推送允诺，也遵循相混思路，最后在index.html文件打印出{“title”:”fontend”,”password”:”123456″}

6.nginx反向代理

同时实现基本上原理类似于Node中间件代理，需要你搭建两个中转nginx服务器，用于转发允诺。

使用nginx反向代理同时实现布吕马，是最简单的布吕马形式。只需要修改nginx的配置即可解决布吕马难题，支持所有应用程序，支持session，不需要修改任何代码，并且不能影响服务器性能。

同时实现思路：透过nginx配置两个代理服务器（搜索引擎与domain1完全相同，路由器相同）做跳板机，反向代理访问domain2接口，并且能顺便修改cookie中domain信息，方便当前域cookie写入，同时实现布吕马登录。

先下载nginx，然后将nginx目录下的nginx.conf修改如下表所示:

// proxy服务器

server {

listen 80;

server_name www.domain1.com;

location / {

proxy_pass http://www.domain2.com:8080; #反向代理

proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里搜索引擎

index index.html index.htm;

# 当用webpack-dev-server等中间件代理接口访问nignx时，此时无应用程序参与，故没有相混管制，下面的布吕马配置可不启用

add_header Access-Control-Allow-Origin http://www.domain1.com; #当前端只布吕马不带cookie时，可为*

add_header Access-Control-Allow-Credentialstrue;

}

}

最后透过命令行nginx-s reload启动nginx

// index.html

var xhr = newXMLHttpRequest();

// 前端开关：应用程序与否读写cookie

xhr.withCredentials = true;

// 访问nginx中的代理服务器

xhr.open(get, http://www.domain1.com:81/?user=admin, true);

xhr.send();

// server.js

var http = require(http);

var server = http.createServer();

var qs = require(querystring);

server.on(request, function(req, res) {

varparams= qs.parse(req.url.substring(2));

// 向后台写cookie

res.writeHead(200, {

Set-Cookie: l=a123456;Path=/;Domain=www.domain2.com;HttpOnly // HttpOnly:脚本无法读取

});

res.write(JSON.stringify(params));

res.end();

});

server.listen(8080);

console.log(Server is running at port 8080…);

window.name属性的独特之处：name值在相同的页面（甚至相同搜索引擎）读取后依旧存在，并且能支持非常长的 name 值（2MB）。

其中a.html和b.html是同域的，都是http://localhost:3000;而c.html是http://localhost:4000

// a.html(http://localhost:3000/b.html)

“http://localhost:4000/c.html” frameborder=”0″ onload=”load()” id=”iframe”>

b.html为中间代理页，与a.html同域，文本为空。

// c.html(http://localhost:4000/c.html)

总结：透过iframe的src属性由外域转向本地域，布吕马统计数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了应用程序的布吕马访问管制，但同时它又是安全可靠操作。

8.location.hash + iframe

同时实现基本上原理： a.html欲与c.html布吕马互相通信，透过中间页b.html来同时实现。 四个页面，相同域间利用iframe的location.hash传值，完全相同域间直接js访问来通信。

具体同时实现步骤：一开始a.html给c.html传两个hash值，然后c.html收到hash值后，再把hash值传递给b.html，最后b.html将结论放到a.html的hash值中。 同样的，a.html和b.html是同域的，都是http://localhost:3000;而c.html是http://localhost:4000

// a.html

“http://localhost:4000/c.html#iloveyou”>

// b.html

// c.html

console.log(location.hash);

let iframe = document.createElement(iframe);

iframe.src = http://localhost:3000/b.html#idontloveyou;

document.body.appendChild(iframe);

该形式只能用于二级搜索引擎完全相同的情况下，比如a.test.com和b.test.com适用于该形式。 只需要给页面添加document.domain=test.com表示二级搜索引擎都完全相同就能同时实现布吕马。

同时实现基本上原理：三个页面都透过js强制设置document.domain为基础主域，就同时实现了同域。

我们看个例子：页面a.

// a.html

helloa

“http://b.zf1.cn:3000/b.html” frameborder=”0″ onload=”load()” id=”frame”>

// b.html

hellob

CORS支持所有类型的HTTP允诺，是布吕马HTTP允诺的根本解决方案

JSONP只支持GET允诺，JSONP的优势在于支持老式应用程序，和能向不支持CORS的网站允诺统计数据。

不管是Node中间件代理还是nginx反向代理，主要是透过相混思路对服务器不加管制。

日常工作中，用得比较多的布吕马方案是cors和nginx反向代理

布吕马天然资源共享 CORS 详解

前端面试之道

window.postMessage

前端常用布吕马解决方案（全）

深入布吕马难题(4) – 利用代认知决布吕马

年度增速最快语言：Rust