夸域脚本

❶ Nginx的反向代理跨域

什么是跨域？

跨域是指a页面想获取b页面资源，如果a、b页面的协议、域名、端口、子域名不同，或是a页面为ip地址， b页面为域名地址，所进行的访问行动都是跨域

浏览器为了安全问题一般都限制了跨域访问，也就是不允许跨域请求资源

同ip（或domain）,同端口，同协议视为同一个域，一个域内的脚本仅仅具有本域内的权限，可以理解为本域脚本只能读写 本域内的资源，而无法访问其它域的资源。这种安全限制称为同源策略

现代浏览器在安全性和可用性之间选择了一个平衡点。 在遵循同源策略的基础上，选择性地为同源策略“开放了后门”。例如img script style等标签，都允许垮域引用资源,然而， 你也只能是引用这些资源而已，并不能读取这些资源的内容

同源策略限制以下几种行为：

1.Cookie、LocalStorage 和 IndexDB 无法读取

2.DOM 和 Js对象无法获得

3.AJAX 请求不能发送

http://www.domain.com/a.jshttp://www.domain.com/b.js 同一域名，不同文件或路径 允许http://www.domain.com/lab/c.jshttp://www.domain.com:8000/a.jshttp://www.domain.com/b.js 同一域名，不同端口 不允许http://www.domain.com/a.jshttps://www.domain.com/b.js 同一域名，不同协议 不允许http://www.domain.com/a.jshttp://192.168.4.12/b.js 域名和域名对应相同ip 不允许http://www.domain.com/a.jshttp://x.domain.com/b.js 主域相同，子域不同 不允许http://domain.com/c.jshttp://www.domain1.com/a.jshttp://www.domain2.com/b.js 不同域名 不允许

1、 通过jsonp跨域

2、 document.domain + iframe跨域

3、 location.hash + iframe

4、 window.name + iframe跨域

5、 postMessage跨域

6、 跨域资源共享（CORS）

7、 nginx代理跨域

8、 nodejs中间件代理跨域

9、 WebSocket协议跨域

正向代理 ：代理位于网站和客户端中间， 客户端无法访问某网站，就将请求发送给代理服务器，代理从网站取回来再发送给客户端，网站并不知道为谁提供服务

反向代理 ：客户端访问某网站的一个页面， 但是网站并没有，就偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户，用户不知道真正提供服务的是谁

对于浏览器来说，访问的就是同源服务器上的一个url。而nginx通过 检测url前缀，把http请求转发到后面真实的物理服务器。并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确 处理请求，并且并不知道这个请求是来自代理服务器的。

简单说，nginx服务器欺骗了浏览器，让它认为这是同源调用，从而解决了浏览器的跨域问题。又通过重写url，欺骗了真实 的服务器，让它以为这个http请求是直接来自与用户浏览器的。

Location/carrots-admin-ajax/{

    proxy_passhttp://dev.admin.carrots.ptteng.com/;

}

proxy_pass 把请求代理到其他主机

两种写法hhttp://dev.admin.carrots.ptteng.com/    和     http://dev.admin.carrots.ptteng.com

    如果访问url = http://server/html/test.jsp ，则被nginx代理后

        情况1，将test/作为根路径，请求test/路径下的资源。

        情况2，则被nginx代理后，请求路径会变为http://proxy_pass/test.jsp，直接访问server的根资源。

是一个匹配规则，用于拦截请求，匹配任何以/proxy/html/开头的地址，匹配符合以后，停止往下搜索正则。

对于浏览器来说，访问的就是同源服务器上的一个url。而nginx通过检测url前缀，把http请求转发到后面真实的物理服务器。并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确处理请求，并且并不知道这个请求是来自代理服务器的。

简单说，nginx服务器欺骗了浏览器，让它认为这是同源调用，从而解决了浏览器的跨域问题。又通过重写url，欺骗了真实的服务器，让它以为这个http请求是直接来自与用户浏览器的。

1.执行server块的rewrite指令(这里的块指的是server关键字后{}包围的区域，其它xx块类似)

2.执行location匹配

3.执行选定的location中的rewrite指令

如果其中某步URI被重写，则重新循环执行1-3，直到找到真实存在的文件

如果循环超过10次，则返回500 Internal Server Error错误

7.参考文献

参考一： https://www.cnblogs.com/gabrielchen/p/5066120.html

参考二： http://blog.csdn.net/shendl/article/details/48443299

8.更多讨论

提问：

Q ：例如img script style等标签，都允许垮域引用资源？

A ：在浏览器中，并且加载的方式其实相当于一次普通的GET请求，唯一不同的是，为了安全起见，浏览器不允许这种方式下对加载到的资源的读写操作，而只能使用标签本身应当具备的能力（比如脚本执行、样式应用等等）。

Q ：例如img script style等标签，都允许垮域引用资源？

A ：在浏览器中，并且加载的方式其实相当于一次普通的GET请求，唯一不同的是，为了安全起见，浏览器不允许这种方式下对加载到的资源的读写操作，而只能使用标签本身应当具备的能力（比如脚本执行、样式应用等等）。

Q：JSONP和nginx跨域有什么不同

JSONP和nginx是完全不同的 是可以跨域的，而且在跨域脚本中可以直接回调当前脚本的函数

原理：是可以跨域的，而且在跨域脚本中可以直接回调当前脚本的函数

script标签是可以加载异域的javaScript并执行的，通过预先设定好的callback函数来实现和母页面的交互。它有一个大名，叫做JSONP跨域，JSONP是JSON with Padding的略称。它是一个非官方的协议，明明是加载script，为啥和JSON扯上关系呢？原来就是这个callback函数，对它的使用有一个典型的方式，就是通过JSON来传参，即将JSON数据填充进回调函数，这就是JSONP的JSON+Padding的含义。JSONP只支持GET请求。

❷ 跨域问题解决方法

跨域？他是浏览器的 同源策略 造成的，是浏览器对javascript施加的安全限制。所谓同源是指：域名、协议、端口均相同。

解决

原理：利用标签具有可跨域的特性，可实现跨域访问接口，需要后端的支持。

服务器在收到请求后，解析参数，计算返还数据，输出messagetow（data）字符串。

缺点：只能发送get请求，无法访问服务器的响应文本（单向请求），即只能获取数据不能改数据。

通过ajax请求不同域的实现，底层不是靠XmlHttpRequest而是script，所以不要被这个方法给迷惑了。

在ajax请求中类型如果是type是get post，其实内部都只会用get，因为其跨域的原理就是用的动态加载script的src，所以我们只能把参数通过url的方式传递

其实jquery内部会转化成

http://192.168.31.137/train/test/jsonpthree?callback=messagetow

然后动态加载http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">

http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron"><script type="text/javascript" src=" http://192.168.31.137/train/test/jsonpthree?callback=messagetow "></script>

http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">

http://192.168.1.114/yii/demos/test.php?backfunc=jQuery2030038573939353227615_1402643146875&action=aaron">

Cross-Origin Resource Sharing（CORS）跨域资源共享是一份浏览器技术的规范，提供了 Web 服务从不同域传来沙盒脚本的方法，以避开浏览器的同源策略，确保安全的跨域数据传输。现代浏览器使用CORS在API容器如XMLHttpRequest来减少HTTP请求的风险来源。与 JSONP 不同，CORS 除了 GET 要求方法以外也支持其他的 HTTP 要求。服务器一般需要增加如下响应头的一种或几种：

跨域请求默认不会携带Cookie信息，如果需要携带，请配置下述参数：

​window.name通过在iframe（一般动态创建i）中加载跨域HTML文件来起作用。然后，HTML文件将传递给请求者的字符串内容赋值给window.name。然后，请求者可以检索window.name值作为响应。

iframe标签的跨域能力；

window.name属性值在文档刷新后依旧存在的能力（且最大允许2M左右）。

每个iframe都有包裹它的window，而这个window是top window的子窗口。 contentWindow 属性返回<iframe>元素的Window对象。你可以使用这个Window对象来访问iframe的文档及其内部DOM。

​ HTML5新特性，可以用来向其他所有的 window 对象发送消息。需要注意的是我们必须要保证所有的脚本执行完才发送 MessageEvent，如果在函数执行的过程中调用了它，就会让后面的函数超时无法执行。

​ 前提条件：这两个域名必须属于同一个基础域名!而且所用的协议，端口都要一致，否则无法利用document.domain进行跨域，所以只能跨子域

​ 在 根域 范围内，允许把domain属性的值设置为它的上一级域。例如，在”aaa.xxx.com”域内，可以把domain设置为 “xxx.com” 但不能设置为 “xxx.org” 或者”com”。

​ 现在存在两个域名aaa.xxx.com和bbb.xxx.com。在aaa下嵌入bbb的页面，由于其document.name不一致，无法在aaa下操作bbb的js。可以在aaa和bbb下通过js将document.name = 'xxx.com';设置一致，来达到互相访问的作用。

WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是server push技术的一种很棒的实现。相关文章，请查看： WebSocket 、 WebSocket-SockJS

**需要注意：**WebSocket对象不支持DOM 2级事件侦听器，必须使用DOM 0级语法分别定义各个事件。

同源策略是针对浏览器端进行的限制，可以通过服务器端来解决该问题,例如nginx

DomainA客户端（浏览器） ==> DomainA服务器 ==> DomainB服务器 ==> DomainA客户端（浏览器）

❸ 怎么解决跨域问题

1、 通过jsonp跨域
JSONP（JSON with Padding：填充式JSON)，应用JSON的一种新方法，
JSON、JSONP的区别：
1、JSON返回的是一串数据、JSONP返回的是脚本代码(包含一个函数调用)
2、JSONP 只支持get请求、不支持post请求
(类似往页面添加一个script标签，通过src属性去触发对指定地址的请求,故只能是Get请求)

2、代理：
www..com/index.html需要调用www.sina.com/server.php，可以写一个接口www..com/server.php，由这个接口在后端去调用www.sina.com/server.php并拿到返回值，然后再返回给index.html
3、PHP端修改header
header(‘Access-Control-Allow-Origin:*’);//允许所有来源访问
header(‘Access-Control-Allow-Method:POST,GET’);//允许访问的方式
4、document.domain
跨域分为两种，一种xhr不能访问不同源的文档，另一种是不同window之间不能进行交互操作;
document.domain主要是解决第二种情况，且只能适用于主域相同子域不同的情况；
document.domain的设置是有限制的，我们只能把document.domain设置成自身或更高一级的父域，且主域必须相同。例如：a.b.example.com中某个文档的document.domain可以设成a.b.example.com、b.example.com 、example.com中的任意一个，但是不可以设成c.a.b.example.com，因为这是当前域的子域，也不可以设成.com，因为主域已经不相同了。
兼容性：所有浏览器都支持；
优点：
可以实现不同window之间的相互访问和操作；
缺点：
只适用于父子window之间的通信，不能用于xhr；
只能在主域相同且子域不同的情况下使用；
使用方式：
不同的框架之间是可以获取window对象的，但却无法获取相应的属性和方法。比如，有一个页面，它的地址是http://www.example.com/a.html ， 在这个页面里面有一个iframe，它的src是http://example.com/b.html, 很显然，这个页面与它里面的iframe框架是不同域的，所以我们是无法通过在页面中书写js代码来获取iframe中的东西的：

<script type="text/javascript">
function test(){
var iframe = document.getElementById('ifame');
var win = document.contentWindow;//可以获取到iframe里的window对象，但该window对象的属性和方法几乎是不可用的
var doc = win.document;//这里获取不到iframe里的document对象
var name = win.name;//这里同样获取不到window对象的name属性
}
</script>
<iframe id = "iframe" src="http://example.com/b.html" onload = "test()"></iframe>
这个时候，document.domain就可以派上用场了，我们只要把http://www.example.com/a.html 和 http://example.com/b.html这两个页面的document.domain都设成相同的域名就可以了。
1.在页面 http://www.example.com/a.html 中设置document.domain:

<iframe id = "iframe" src="http://example.com/b.html" onload = "test()"></iframe>
<script type="text/javascript">
document.domain = 'example.com';//设置成主域
function test(){
alert(document.getElementById('iframe').contentWindow);//contentWindow 可取得子窗口的 window 对象
}
</script>
2.在页面 http://example.com/b.html 中也设置document.domain:

<script type="text/javascript">
document.domain = 'example.com';//在iframe载入这个页面也设置document.domain，使之与主页面的document.domain相同
</script>
5、window.name
关键点：window.name在页面的生命周期里共享一个window.name;
兼容性：所有浏览器都支持；
优点：
最简单的利用了浏览器的特性来做到不同域之间的数据传递；
不需要前端和后端的特殊配制；
缺点：
大小限制：window.name最大size是2M左右，不同浏览器中会有不同约定；
安全性：当前页面所有window都可以修改，很不安全；
数据类型：传递数据只能限于字符串，如果是对象或者其他会自动被转化为字符串，如下；
这里写图片描述
使用方式：修改window.name的值即可；
6、postMessage
关键点：
postMessage是h5引入的一个新概念，现在也在进一步的推广和发展中，他进行了一系列的封装，我们可以通过window.postMessage的方式进行使用，并可以监听其发送的消息；
兼容性：移动端可以放心用，但是pc端需要做降级处理
优点
不需要后端介入就可以做到跨域，一个函数外加两个参数（请求url，发送数据）就可以搞定；
移动端兼容性好；
缺点
无法做到一对一的传递方式：监听中需要做很多消息的识别，由于postMessage发出的消息对于同一个页面的不同功能相当于一个广播的过程，该页面的所有onmessage都会收到，所以需要做消息的判断；
安全性问题：三方可以通过截获，注入html或者脚本的形式监听到消息，从而能够做到篡改的效果，所以在postMessage和onmessage中一定要做好这方面的限制；
发送的数据会通过结构化克隆算法进行序列化，所以只有满足该算法要求的参数才能够被解析，否则会报错，如function就不能当作参数进行传递；
使用方式：通信的函数，sendMessage负责发送消息，bindEvent负责消息的监听并处理，可以通过代码来做一个大致了解；

Storage.prototype.sendMessage_ = function(type, params, fn) {
if (this.topWindow) {
this.handleCookie_(type, params, fn);
return;
}
var eventId = this.addToQueue_(fn, type);
var storageIframe = document.getElementById('mip-storage-iframe');
var element = document.createElement("a");
element.href = this.origin;
var origin = element.href.slice(0, element.href.indexOf(element.pathname) + 1);
storageIframe.contentWindow.postMessage({
type: type,
params: params,
eventId: eventId
}, origin);
}
Storage.prototype.bindEvent_ = function() {
window.onmessage = function (res) {
// 判断消息来源
if (window == res.source.window.parent &&
res.data.type === this.messageType.RES &&
window.location.href.match(res.origin.host).length > 0) {
var fn = this.eventQueue[res.data.eventId];
fn && fn();
delete this.eventQueue[res.data.eventId];
// reset id
var isEmpty = true;
for (var t in this.eventQueue) {
isEmpty = false;
}
if (isEmpty) {
this.id = 0;
}
}
}.bind(this);
}

❹ 使用Openresty时配置解决跨域问题

实现系统架构简图如下：

一、编写脚本

1、新建handle_cors.lua脚本文件

二、配置Nginx

1.配置nginx.conf信息

在server里对需要跨域的url添加

参考：https://blog.csdn.net/u010277446/article/details/78654491

踩坑：访问Openresty服务器时，使用postman、curl都是可以调通接口接收到正确响应的，但是在swagger-ui页面中执行execute时，总是返回403，“TypeError: Failed to fetch”！使用如下所示针对nginx的跨域配置是无效的，只有根据上述方法，使用lua脚本设置才起作用。

#

# Wide-open CORS config for nginx

#

location / {

    if ($request_method = 'OPTIONS') {

        add_header 'Access-Control-Allow-Origin' '*';

        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

        #

        # Custom headers and headers various browsers *should* be OK with but aren't

        #

        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';

        #

        # Tell client that this pre-flight info is valid for 20 days

        #

        add_header 'Access-Control-Max-Age' 1728000;

        add_header 'Content-Type' 'text/plain; charset=utf-8';

        add_header 'Content-Length' 0;

        return 204;

    }

｝

❺ web前端面试题@二（Keeplive、V-show和v-if的区别、同源策略及跨域）

            在vue中，我们使用component内置组件或者vue-router切换视图的时候，由于vue会主动卸载不使用的组件，所以我们不能保存组件之前的状态，而我们经常能遇到需要保存之前状态的需求，例如：搜索页（保存搜索记录），列表页（保存之前的浏览记录）等等。

            Keep-alive是一个vue的内置组件，它能将不活动的组件保存下来，而不是直接销毁，当我们再次访问这个组件的时候，会先从keep-alive中存储的组件中寻找，如果有缓存的话，直接渲染之前缓存的，如果没有的话，再加载对应的组件。

            作为抽象组件，keep-alive是不会直接渲染在DOM中的。

        Keep-alive提供了三种可选属性

        Include-字符串或数组或正则表达式。只有名称匹配的组件被缓存。

        Exclude -字符串或数组或正则表达式。名称匹配的组件不会被缓存。

        Max -数字类型。表示最多可以缓存多少组件实例。

        Keep-alive提供了两个生命钩子，分别是activated与 deactivated。

        因为Keep-alive会将组件保存在内存中，并不会销毁以及重新创建，所以不会重新调用组件的created等方法，需要用activated与deactivated这两个生命钩子来得知当前组件是否处于活动状态。

        V-show有较高的渲染成本，

        V-if有较高的切换成本。

        V-if是真正的条件渲染，确保切换过程中条件内的事件监听器和子组件适当的被销毁和重建。

        V-show的元素始终被渲染并保存在dom中，操作的只是display属性控制演示影藏。

        源（origin）—— 就是协议、域名和端口号。若地址里面的协议、域名和端口号均相同则属于同源。

        同源策略——同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以a.com下的js脚本采用ajax读取b.com里面的文件数据是会报错的。

    不受同源策略限制的

            1.页面中的链接，重定向以及表单提交是不会受到同源策略限制的。

            2.跨域资源的引入是可以的。但是js不能读写加载的内容。如嵌入到页面中的<script src="..."></script>，<img>，<link>，<iframe>等。

     跨域——只要协议、域名、端口号有一个不同就是跨域。

        跨域的原因？（只做了解）

跨域问题来源于JavaScript的同源策略，即只有 协议+主机名+端口号(如存在)相同，则允许相互访问。为了防止某域名下的接口被其他域名下的网页非法调用，是浏览器对JavaScript施加的安全限制。也就是说JavaScript只能访问和操作自己域下的资源，不能访问和操作其他域下的资源。跨域问题是针对JS和ajax的，html本身没有跨域问题，比如a标签、script标签、甚至form标签（可以直接跨域发送数据并接收数据）等。

       1、 Jsonp——

                利用script标签可跨域的特点，在跨域脚本中可以直接回调当前脚本的函数。jsonp是一种常用的跨域手段，和反向代理，服务端做跨域处理相比，jsonp更显得方便轻巧 jsonp的缺点只能发送get请求。因为script只能发送get请求需要后台配合。此种请求方式应该前后端配合，将返回结果包装成callback(result)的形式。

       2、 Cors——

                服务器设置HTTP响应头中Access-Control-Allow-Origin值，解除跨域限制。CORS 是一个W3C标准,全称是"跨域资源共享"（Cross-origin resource sharing），他允许浏览器向跨源服务器发送XMLHttpRequest请求，从而克服 AJAX 只能同源使用的限制

                缺点是：目前所有最新浏览器都支持该功能，但是万恶的IE不能低于10

Access-Control-Allow-Origin 这个字段是必须的,表示接受那些域名的请求(*为所有)、Access-Control-Allow-Credentials 该字段可选, 表示是否可以发送cookie、Access-Control-Expose-Headers 该字段可选,XHMHttpRequest对象的方法只能够拿到六种字段: Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma ,如果想拿到其他的需要使用该字段指定。

       3、反向代理（Reverse Proxy）{前端独立就能解决的跨域方案}——

    指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

    

❻ 用flash去连接socket服务器，能不能不用crossdomain.xml文件

1、Loader加载图片或者swf，只要不是加载到同个安全域，都不需要拉取crossdomain.xml。获取在LoaderContext指定true，必须拉取。
但如果后续，要读取图片或者swf里边内容，例如设置图片smoothing或者draw，都需要拉取这个文件

如果文件不存在，会抛出安全沙箱冲突

可以手工security.loadPolicyFile，也可以在loader中设置loader.load(new URLRequest("http://xxxxxxxx/xxxx.jpg"),new LoaderContext(true));
但必须代码中指定拉取策略文件才会去拉取，flash不会自动拉取。如果到了截图的时候发现没有拉取这个文件，就会报错。

2、URLLoader请求的内容，flash会先自动请求crossdomain.xml，如果得到授权后再请求指定内容。

3、对于swf，如果要调用其他域名下的swf的脚本，还需要有Security.allowDomain()
http://help.adobe.com/zh_CN/AS2LCR/Flash_10.0/help.html?content=00001493.html

如果两个 SWF 文件是同一个域提供，例如，http://mysite.com/movieA.swf 和
http://mysite.com/movieB.swf，则 movieA.swf 可以检查和修改 movieB.swf 中的变量、对象、属性、方法等，而且 movieB.swf 也可以对 movieA.swf 执行同样的操作。这被称为跨影片脚本编写 或简称跨脚本编写。
如果从不同的域提供两个 SWF 文件（例如 http://mysite.com/movieA.swf 和
http://othersite.com/movieB.swf），则在默认情况下，Flash Player 既不允许 movieA.swf 编写 movieB.swf 的脚本，也不允许 movieB.swf 编写 movieA.swf 的脚本。通过调用 System.security.allowDomain()，一个 SWF 文件可授予其它域中的 SWF 文件编写其脚本的权限。这称为跨域脚本编写。通过调用 System.security.allowDomain("mysite.com")，movieB.swf 授予 movieA.swf 编写 movieB.swf 的脚本的权限。

使用 System.security.allowDomain() 建立的跨域权限是不对称的。在上一个示例中，movieA.swf 可以编写 movieB.swf 的脚本，但 movieB.swf 无法编写 movieA.swf 的脚本，这是因为 movieA.swf 未调用 System.security.allowDomain() 来授予 othersite.com 编写 movieA.swf 的脚本的权限。可以通过让两个 SWF 文件都调用 System.security.allowDomain() 来设置对称权限。

当然，有crossdomain.xml文件前提下，可以直接用urlloader加载回来，然后在loader.loadBytes，这样就放到同一个程序域内了，没有上述限制了。

❼ 跨域的几种方法

浏览器出于安全方面的考虑，只允许客户端与本域（同协议、同域名、同端口，三者缺一不可）下的接口交互。不同源的客户端脚本在没有明确授权的情况下，不能读写对方的资源，这被称为同源策略。

而有时候，我们不得不在一个客户端下访问不同域中的资源，于是需要用到一些方法来避开浏览器的同源策略，这些方法被称为跨域。
实现跨域有如下几种方法：

JSONP（JSON with Padding）是数据格式JSON的一种使用模式，可以使网页实现跨域请求。其原理主要利用了 HTML 的 script 标签。由于 script 是采用开放策略，通过设置 src 引入不同域下的资源，所以可以通过 script 实现跨域，该方法需要后端支持。jsonp跨域的实现步骤如下：

下面来做个演示，首先为演示方便，将系统的hosts做如下修改：

以上例子最终实现了由example.a.com到example.b.com的跨域。应注意的是，因为 <script> 只能发送GET请求，所以jsonp只能实现GET请求的跨域。如果希望能实现其他请求的跨域，就可以用接下来介绍的一种方法——CORS。

CORS（全称为：Cross-Origin Resouce Sharing）跨域资源共享，是一种通过ajax跨域请求资源的方法。浏览器将CORS请求分为两大类，简单请求（simple request）和非简单请求（not-so-simple request，浏览器对这两种请求的处理方式不一样。如果请求满足以下两个条件，则为简单请求。

简单请求的实现方式即当用XMLHttpRequest发请求时，浏览器如果发现该请求不符合同源策略，会给该请求加上一个请求头origin，origin用来说明本次请求来自哪个源（协议+域名+端口）。如果origin指定的源不在后台允许范围内，后台会返回一个正常的HTTP响应，然后浏览器会发现该响应头部信息不包含Access-Control-Allow-Origin字段，然后抛出一个错误，该错误被XMLHttpRequest的onerror函数捕获，响应被驳回，但因为该错误无法通过状态码识别，所以HTTP回应的状态码还是200。如果origin在后台允许范围内，则服务器返回的响应，会包含Access-Control-Allow-Origin：Origin（指定的源）信息，浏览器此时不会抛错，响应能正常处理。
非简单请求是是请求方法为PUT或DELETE，又或者Content-Type为application/json的对服务器有特殊要求的请求。非简单请求的CORS请求，会在正式通信前增加一次HTTP查询，称为预检（preflight），询问服务器当前网页所在域名是否在服务器的许可名单中，如果在，则发出正式的XMLHttpRequest，之后就与简单请求一样，不在则报错。
依旧用上面的例子。

最终实现的效果与第一个jsonp的例子一样。

还有一种方式，就是通过降域来实现跨域。即通过设置document.domain的方式，将两个域名的domain设置为一个，如对于a.example.com和b.example.com，可以通过js设置 document.domain = "example.com" ，实现跨域。
做个演示，假设在 http://a.example.com:8080 下有一个a.html文件，其中a.html中有一个 iframe ，它的 src 为 http://b.example.com:8080/b.html 。

用降域方法实现跨域操作简单，但是有一些缺点。比如域名只能往下设置，不能回去，比如从example.com回到a.example.com。同时如果一个子域名被攻击，多个被降域的域名都会被连带攻击，有很大的安全风险。

postMessage是一个web API，可以实现跨域通信。 window.postMessage() 被调用时，会在所有页面脚本执行完毕后，向目标窗口派发一个 MessageEvent 消息。语法如下：

MessageEvent 具有如下属性：

用一个与上面降域类似的例子来做演示。同样有两个页面a.html和b.html，a.html中的 iframe 的 src 指向b.html。

最终实现a.html与b.html通信效果如下：

使用postMessage方法应注意的是，如果不希望从其他网站接收message，那么不要为message事件添加任何监听器。如果确实希望接收其他网站的message，那么应该始终使用origin和source属性来验证发件人的身份，以免被恶意的网站攻击。

以上就是几种常见的跨域方法，各有优劣，且各自都有一定的安全问题，在日常应用中，需要有针对性的使用，对可能的安全风险采取相应措施。

❽ vue 如何实现跨域

跨域问题是因为浏览器的同源策略引起的，一种浏览器的安全机制，要求 协议，域名，端口 ，都要一致！

出于浏览器的同源策略限制，浏览器会拒绝跨域请求。

什么叫跨域？非同源请求，均为跨域。名词解释：同源 —— 如果两个页面拥有相同的协议（protocol），端口（port）和主机（host），那么这两个页面就属于同一个源（origin）。

怎么解决跨域？最常用的三种方式： JSONP、CORS、postMessage 。

jsonp，只支持get，不支持post，需要调用前端和被调用后端配合（比较常用）

后端HttpClient进行转发，两次请求，效率低，安全（类似Nginx反向代理）

服务端设置响应头，允许跨域，适于小公司快速解决问题

Nginx搭建API接口网关

Zuul搭建API接口网关

后四种都属于服务端设置，对于目前还是一个纯前端的我来说，先把前端的搞懂再说，所以在此只说前端

jsonp工作原理理解

jsonp实际上是通过动态插入js的方式实现的跨域，因为通过script标签引入js文件没有跨域一说

web客户端通过调用脚本的方式去调用跨域服务端动态生成的js文件（一般以json为后缀），同时传递一个callback参数给服务端，服务端以这个参数名为函数名，调用此函数以参数的形式将数据传到web端，这样就实现了前端跨域请求服务端数据。

【JSONP的优缺点】

优点：兼容性好（兼容低版本IE）

缺点：1.JSONP只支持GET请求； 2.XMLHttpRequest相对于JSONP有着更好的错误处理机制

CORS ：是W3C 推荐的一种新的官方方案，能使服务器支持 XMLHttpRequest 的跨域请求。CORS 实现起来非常方便，只需要增加一些 HTTP 头，让服务器能声明允许的访问来源。

postMessage : window.postMessage(message,targetOrigin) 方法是html5新引进的特性，可以使用它来向其它的window对象发送消息，无论这个window对象是属于同源或不同源，目前IE8+、FireFox、Chrome、Opera等浏览器都已经支持 window.postMessage方法。

❾ 手机APP和web服务端 跨域问题

跨域问题来源于JavaScript的同源策略，即只有 协议+主机名+端口号 (如存在)相同，则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源，不能访问和操作其他域下的资源。
在以前，前端和后端混杂在一起， 比如JavaScript直接调用同系统里面的一个Httphandler，就不存在跨域的问题，但是随着现代的这种多种客户端的流行，比如一个应用通常会有Web端，App端，以及WebApp端，各种客户端通常会使用同一套的后台处理逻辑，即API， 前后端分离的开发策略流行起来，前端只关注展现，通常使用JavaScript，后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样，通过ajax请求WebService的时候，就会出现同源策略的问题。
需要说明的是，同源策略是JavaScript里面的限制，其他的编程语言，比如在C#，Java或者iOS等其他语言中是可以调用外部的WebService，也就是说，如果开发Native应用，是不存在这个问题的，但是如果开发Web或者Html5如WebApp，通常使用JavaScript ajax对WebService发起请求然后解析返回的值，这样就可能存在跨域的问题。
一般的，很容易想到，将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面，所有JavaScript的请求都发到这个页面上来，这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题，但是不够直接和高效。
目前，比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP，一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案，以及服务端WebService如何支持这两种跨域方案。
JSONP以及WebService的支持
同源策略下，某个服务器是无法获取到服务器以外的数据，但是html里面的img,iframe和script等标签是个例外，这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。
当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装，客户端就可以处理。
举个例子，服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
http://www.example.net/sample.aspx?callback=mycallback

如果没有后面的callback参数，即不使用JSONP的模式，该服务的返回结果可能是一个单纯的json字符串，比如：
{ foo : 'bar' }

如果和服务端约定jsonp格式，那么服务端就会处理callback的参数，将返回结果进行一下处理，比如处理成：
mycallback({ foo : 'bar' })

可以看到，这其实是一个函数调用，比如可以实现在页面定义一个名为mycallback的回调函数：
mycallback = function(data)
{
alert(data.foo);
};

现在，请求的返回值回去触发回调函数，这样就完了了跨域请求。
如果使用ServiceStack创建WebService的话，支持Jsonp方式的调用很简单，只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}

JSONP跨域方式比较方便，也支持各种较老的浏览器，但是缺点很明显，他只支持GET的方式提交，不支持其他Post的提交，Get方式对请求的参数长度有限制，在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。
CORS跨域及WebService的支持
先来看一个例子，我们新建一个基本的html页面，在里面编写一个简单的是否支持跨域的小脚本，如下：
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域请求测试</title>
</head>
<body>
<input type='button' value='开始测试' onclick='crossDomainRequest()' />
<div id="content"></div>

<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "开始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能创建 XMLHttpRequest";
}
}

function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "结果：" + response;
} else {
document.getElementById("content").innerHTML = "不允许跨域请求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>执行状态 readyState：" + xhr.readyState;
}
}
//]]>
</script>

</body>
</html>

然后保存为本地html文件，可以看到，这个脚本中，对本地的服务http://localhost:1337/json/Hello 发起了一个请求， 如果使用chrome 直接打开，会看到输出的结果，不允许跨域请求。 在javascript控制台程序中同样可以看到错误提示：

那么如果在返回响应头header中注入Access-Control-Allow-Origin，这样浏览器检测到header中的Access-Control-Allow-Origin，则就可以跨域操作了。
同样，如果使用ServcieStack，在很多地方可以支持CORS的跨域方式。最简单的还是在AppHost的Configure函数里面直接写入：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}

这样就可以了，相当于使用默认的CORS配置：
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);

如果仅仅允许GET和POST的请求支持CORS，则只需要改为：
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));

当然也可以在AppHost的Config里面设置全局的CORS，如下：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{

base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}

现在运行WebService，使用postman或者Chrome调用这个请求，可以看到返回的值头文件中，已经加上了响应头，并且可以正常显示返回结果了：

CORS使用起来简单，不需要客户端的额外处理，而且支持Post的方式提交请求，但是CORS的唯一一个缺点是对客户端的浏览器版本有要求，支持CORS的浏览器机器版本如下：

总结
本文介绍了JavaScript中的跨域基本概念和产生的原因，以及如何解决跨域的两种方法，一种是JSONP 一种是 CORS,在客户端Javascript调用服务端接口的时候，如果需要支持跨域的话，需要服务端支持。JSONP的方式就是服务端对返回的值进行回调函数包装，他的优点是支持众多的浏览器， 缺点是仅支持Get的方式对服务端请求。另一种主流的跨域方案是CORS，他仅需要服务端在返回数据的时候在相应头中加入标识信息。这种方式非常简便。唯一的缺点是需要浏览器的支持，一些较老的浏览器可能不支持CORS特性。
跨域支持是创建WebService时应该考虑的一个功能点，希望本文对您在这边面有所帮助，文中是使用ServiceStack来演示跨域支持的，如果您用的WCF的话，知道跨域原理的前提下，实现跨域应该不难。

参考资料：
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp

❿ HTML5 script 标签的 crossorigin 属性到底有什么用

最近 Bootstrap 4 已经正式发布了，可能已经有爱尝鲜的小伙伴在 alpha 阶段就尝试过 BS4。不过今天要说的不是 BS4，而是官网里引入 BS4 框架依赖的 jQuery 的代码：

XHTML
1
2
3
<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js"
integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN"
crossorigin="anonymous"></script>

看起来比以前的写法复杂好多的样子。先不着急慢慢看，多了一个 integrity 属性，看值的样子就知道是用来验证文件完整性的。另外还有一个 crossorigin 属性……怎么？直接通过 script 标签加载网站外 JS 资源也要开始考虑跨域的问题了吗？

这里不讨论 script 里 crossorigin 属性怎么用，以及服务器端如何支持此属性，MDN 上的文档已经说得很清楚。

不知道大家对此新属性的感觉如何，我的第一感觉是：新加了这么一个属性，难道是以前 script 不用 crossorigin 属性的时候，会出什么问题吗？到底可能会出什么问题呢？

从谷歌的结果来看，比较一致的说法是，引入跨域的脚本（比如用了 apis.google.com 上的库文件），如果这个脚本有错误，因为浏览器的限制（根本原因是协议的规定），是拿不到错误信息的。当本地尝试使用 window.onerror 去记录脚本的错误时，跨域脚本的错误只会返回 Script error。

script error

但 HTML5 新的规定，是可以允许本地获取到跨域脚本的错误信息，但有两个条件：一是跨域脚本的服务器必须通过 Access-Controll-Allow-Origin 头信息允许当前域名可以获取错误信息，二是当前域名的 script 标签也必须指明 src 属性指定的