什么是跨域请求

1.浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域

2.只要协议、域名、端口有任何一个不同，都被当作是不同的域，之间的请求就是跨域操作。

协议http和https不同，端口80还是81，域名更好理解

跨域限制主要是为了安全考虑

浏览器的同源策略会导致跨域，这里同源策略又分为以下两种DOM同源策略：

1.禁止对不同源页面DOM进行操作。这里主要场景是iframe跨域的情况，不同域名的iframe是限制互相访问的。

2.XmlHttpRequest同源策略：禁止使用XHR对象向不同源的服务器地址发起HTTP请求。

https://blog.csdn.net/tjcjava/article/details/76468225

基本原理就是通过动态创建script标签,然后利用src属性进行跨域。

这么说比较模糊，我们来看个例子:// 定义一个fun函数

返回的js脚本，直接会执行。所以就执行了事先定义好的fun函数了，并且把数据传入了进来。

当然，这个只是一个原理演示，实际情况下，我们需要动态创建这个fun函数，并且在数据返回的时候销毁它。因为在实际使用的时候，我们用的各种ajax库，基本都包含了jsonp的封装，不过我们还是要知道一下原理，不然就不知道为什么jsonp不能发post请求了

浏览器有跨域限制，但是服务器不存在跨域问题，所以可以由服务器请求所要域的资源再返回给客户端。

对于主域名相同，而子域名不同的情况，可以使用document.domain来跨域 这种方式非常适用于iframe跨域的情况，直接看例子吧 比如a页面地址为 http://a.yourhost.com b页面为 http://b.yourhost.com 。 这样就可以通过分别给两个页面设置 document.domain = http://yourhost.com 来实现跨域。 之后，就可以通过 parent 或者 window[‘iframename’]等方式去拿到iframe的window对象了。

window.name跨域同样是受到同源策略限制，父框架和子框架的src必须指向统一域名。window.name的优势在于，name的值在不同的页面(或者不同的域名)，加载后仍然存在，除非你显示的更改。并且支持的长度达到2M.

服务端的解决方案的基本原理就是，由客户端将请求发给本域服务器，再由本域服务器的代理来请求数据并将响应返回给客户端。

最常用的服务器解决方案就是利用web服务器本身提供的proxy功能，如apache和lighttpd的mod_proxy模块。在百度内

部，transmit的分流功能也可以解决部分跨域问题。但这些方法都有一定的局限性，鉴于安全性等问题的考虑，space这边最后开发了一个专门用于处

理跨域请求代理服务的spproxy模块，用于彻底解决js跨域问题。

下面我们将以空间的开放平台为例，简单介绍下如何通过apache的mod_proxy、transmit的分流以及space的spproxy模块来解

决该跨域问题，并简单介绍下spproxy的一些特性、缺点及下一步的改进计划。

空间在展现每个UWA开放模块之前都必须请求该模块的xml源代码以进行解析，每个模块的源代码文件都是存放在act域下的/ow/uwa目录下，那么在

用户空间首页（hi域）中请求该xml文件时就会存在js跨域问题。要解决该问题，只能让js向hi域的web服务器请求xml文件，而hi域web服务

器则通过一定的代理机制（如mod_proxy、transmit分流、spproxy）向act域的web服务器请求文件

参考文章： https://mp.weixin.qq.com/s/Re1fvKKzi-rPpu6SmpqTJA

说到跨域问题，我们最常见的就是在我们向服务器发起请求的时候会遇到。比如说如下情况

假设我们正在访问 https://api.mysebsite.com 的站点，当我们点击按钮，向 https://api.mysebsite/users.com 发送请求，获取网站上的一些用户信息。这个时候从结果上是完美的。原因是，根据 同源策略 ，我们发起请求的 域名 ， 端口 ， 协议 均是一至的。浏览器并不会产生跨域报错。

而如果，以上提到的三点其中一点不满足的站点，再向服务器发起请求，那么这个时候就会触发跨域报错。如下图

而以上两种情况出现的原因，其实就是我们今天要介绍的内容。

首先我们先来介绍一下同源策略

浏览器网络请求的时候，有一个 同源策略 的机制，即默认情况下，使用API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源。也就是我们上面提到的，必须要求域名，端口，协议都要一至。请求才能发送成功。而只要其中一点不一致，那么该请求也算是跨域的。

所以我们同样可以看得出来。同源策略会限制以下三种行为:

说了这么多其实，我们可以看出同源策略的作用其实就是为了保证用户的信息安全。打个比方，如果没有同源策略，那么当你在不小心的情况下，点击了网页的钓鱼网站。然后恶意的网站很容易就能利用重定向把你带到一个iframe 的 攻击网站，这个iframe会自动加载银行网站，并通过Cookie登录你的账号。然后操作你的DOM，进行一系列的危险操作。

而我们当然不希望这种情况发生，这个时候同源策略就起到有效的保护作用。因为它确保了我们只能访问同一站点的资源

好了，接下来要说的就是CORS了。

浏览器出于安全的考虑，会限制 从脚本内发起 的跨域HTTP请求。（注意是脚本内）例如XHR 和 Fetch 就遵循同源策略。这意味着使用 API 的Web应用程序只能从加载应用程序的同一个域请求HTTP资源。

在日常的开发中，我们很多时候都会跨域去请求别的站点的资源。而这个时候我们为了解决跨域的问题就要利用CORS机制。

CORS(Cross-Origin Resource Sharing)，即 跨域资源共享 。如字面意思，CORS机制的存在就是为了让我们在保证安全的前提下，实现访问不同域下的资源，这算是放宽的政策。

浏览器可以利用CORS机制，放行一些符合规范的跨域访问，阻止不符合规范的跨域访问。下面我我们就来介绍一下浏览器内部是如何实现的。

Web程序发出跨域请求后，浏览器会 自动 向我们的HTTP header添加一个额外的字段 Origin 。 Origin 标记了请求的站点来源:

为了使浏览器允许访问跨域资源，服务器返回的 response 还需要加一些响应头字段，这些字段可以 显式 的表明此服务器是否允许跨域请求。

作为服务端人员，我们为了允许符合规则的跨域请求。我们可以通过在HTTP的响应中添加响应字段 Access-Control-* 来表明是否允许跨域请求。根据这些CORS响应头字段，浏览器可以允许一些被同源策略限制的跨域响应

虽然有好几个CORS的字段，但是有一个必须要加的字段是 Acess-Control-Allow 。这个头字段的值指定了哪些站点被允许跨域访问资源的。

现在这个字段会被添加到服务端的响应报文中，然后返回给客户端。然后这个时候客户端再向服务端发起跨域请求，同源策略将不会再限制 https://api.mywebsite.com 站点返回的资源。

报文如下：

而相反，如果对比 Access-Control-Allow-Origin 和 Origin 的值不一致的时候，浏览器会抛出一个 CORS Error的报错信息。

除了 Access-Control-Allow-Origin 字段头之外，开发人员还可以通过其他字段对请求作出限制。比如说 Access-Control-Allow-Methods 该字段用来指明跨域请求所允许的 HTTP 方法。

如上图中，只有请求方法为 GET ， POST 或 PUT 方法被允许跨域访问资源。其他的HTTP方法，例如 PATCH 和 DELETE 都会产生预检。

这里就引申出一些别的内容，比如说 预检

什么是预检呢？

到这里，CORS和跨域的关系基本就说清楚了。下面我们再说一点补充

XHR 或 Fetch 与 CORS的一个有趣的特性是，我们可以基于 Cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XHR 或 Fetch 请求，浏览器 不会 发送身份凭证信息。

尽管 CORS 默认 情况下不发送身份凭证，但我们仍然可以通过添加 Access-Control-Allow-Credentials CORS响应头来更改它

如果要在跨域请求中包含 cookie 和其他授权信息，我们需要做一下操作:

做到了上面几点之后，就能在跨域请求中携带身份凭证了。

以上就是全部内容了

补充参考： http://www.goodpm.net/postreply/csharp/1010000008959813/AccessControlAllowOrigin%E5%A6%82%E4%BD%95%E8%AE%BE%E7%BD%AE%E5%A4%9A%E4%B8%AA%E5%80%BC%E5%91%A2.html

---