解决跨域问题

什么是同源策略？

同源策略是浏览器的一项最为基本同时也是必须遵守的安全策略。同源策略的存在，限制了“源”自A的脚本只能操作“同源”页面的DOM，“跨源”操作来源于B的页面将会被拒绝。所谓的“同源”，必须要求相应的URI在如下3个方面均是相同的。

1. 主机名称（域名/子域名或者IP地址）
2. 端口号
3. 网络协议（Scheme，分别采用“http”和“https”协议的两个URI被视为不同源

对于一段JavaScript脚本来说，其“源”与它存储的地址无关，而取决于脚本被加载的页面。比如在某个页面中通过<script>标签引用了来源于不同地方的两个JavaScript脚本，它们均与当前页面同源。

<script src="http://www.a.com/scripts/a.js"></script>
<script src="http://www.b.me/scripts/b.js"></script>

除了<script>标签其它一些具有src属性的标签（比如<img>），它们均具有跨域加载资源的能力，所以同源策略对它们不做限制。

同源策略主要限制了通过XMLHttpRequest实现的Ajax请求，如果请求的是一个“异源”地址，浏览器将不允许读取返回的内容。

JSONP实现跨域资源共享

通过<script>标签的src属性加载的JavaScript脚本

<script type="text/javascript" src="http://localhost:8080/api/test?callback=test"></script>

<script type="text/javascript">
function test(arg){

}
</script>

JSONP是利用<script>的src标签加载的脚本不受同源策略约束而采取的一种编程技巧，不是一种官方协议。由于具有src属性的HTML标签均通过HTTP-GET的方式来加载目标资源，JSONP只适用于HTTP-GET请求。

我们可以利用JQuery发送JSONP的Ajax跨域请求，调用$.ajax方法并将dataType参数设置为“jsonp”

<script type="text/javascript">
    $(function ()
    {
        $.ajax({
             dataType : "jsonp"
        });
    });
</script>

CORS（Cross-Origin Resource Sharing）

基于Web的资源共享涉及到两个基本的角色，即资源的提供者和消费者。即显示在浏览器中的某个Web页面通过调用Web API的方式来获取它所需的资源，资源提供者为Web API本身，通过发送Ajax请求来调用Web API的JavaScript程序为资源的消费者。

CORS旨在定义一种规范让浏览器在接收到从提供者获取的资源时能够正决定是否应该将此资源分发给消费者作进一步处理。CROS利用资源提供者的显式授权来决定目标资源是否应该与消费者共享。浏览器需要得到提供者的授权之后才会将其提供的资源分发给消费者。

如果浏览器 自身提供对CROS的支持，由它发送的请求会携带一个名为“Origin”的报头表明请求页面所在的站点。

资源获取请求被提供者接收之后，它可以根据该报头确定提供的资源需要共享给谁。资源提供者的授权通过一个名为“Access-Control-Allow-Origin”的响应报头来承载，其报头值表示得到授权的站点。一般来说，如果资源的提供者认可了当前请求的“Origin”报头携带的站点，那么它会将该站点作为“Access-Control-Allow-Origin”响应报头的值。

当浏览器接收到包含资源的响应之后，会提取此“Access-Control-Allow-Origin”响应报头的值。如果此值为“*”或者包含的源列表包含此前请求的源（即请求的“Origin”报头值），意味着资源的消费者获取了提供者获取和操作资源的权限，所以浏览器会允许JavaScript程序操作获取的资源。如果此响应报头不存在或者其值为“null”，客户端JavaScript程序针对资源的操作会被拒绝。

简单（HTTP）方法（Simple Method）”、“简单（请求）报头（Simple Header）”和“自定义请求报头（Author Request Header/Custom Request Header）”

CORS规范将GET、HEAD和POST这三个HTTP方法视为“简单HTTP方法”，而将请求报头Accept, Accept-Language, Content-Language以及采用如下三种媒体类型的报头Content-Type称为“简单请求报头”

1. application/x-www-form-urlencoded
2. multipart/form-data
3. text/plain

由JavaScript程序自行添加的报头（比如调用XMLHttpRequest的setRequestHeader方法可以为生成的Ajax请求添加任意报头），被称为“自定义报头”。

简单请求/非简单跨域资源请求

CORS规范将服务如下条件的跨域资源请求划分为简单请求：请求采用简单HTTP方法，并且其自定义请求报头空或者所有自定义请求报头均为简单请求报头。

对于简单跨域资源请求来说，浏览器将两个步骤（取得授权和获取资源）合二为一。如果针对请求的处理过程会涉及到对资源的改变，这样做就会有问题了。按照CORS规范的规定，浏览器应该采用一种被称为“预检”的机制来完成非简单跨域资源请求。

所谓预检机制就是说浏览器在发送真正的跨域资源请求前，先发送一个预检请求。预检请求为一个采用HTTP-OPTIONS方法的请求，这是一个不包含主体的请求，同时用户凭证相关的报头也会被剔除。基于真正资源请求的一些辅助授权的信息会包含在此预检请求的相应报头中。除了代表请求页面所在站点的“Origin”报头之外，如下所示的是两个典型的请求报头。

1. Access-Control-Request-Method：真正跨域资源请求采用的HTTP方法。
2. Access-Control-Request-Headers：真正跨域资源请求携带的自定义报头列表。

资源的提供者在接收到预检请求之后，根据其提供的相关报头进行授权检验，具体的检验逻辑即包括确定请求站点是否值得信任，以及请求采用HTTP方法和自定义报头是否被允许。如果预检请求没有通过授权检验，资源提供者一般会返回一个状态为“400， Bad Reuqest”的响应。反之则会返回一个状态为“200， OK”的响应，授权相关信息会包含在响应报头中。除了上面介绍的“Access-Control-Allow-Origin”报头之外，预检请求的响应还具有如下3个典型的报头。

1. Access-Control-Allow-Methods：跨域资源请求允许采用的HTTP方法列表。
2. Access-Control-Allow-Headers：跨域资源请求允许携带的自定义报头列表。
3. Access-Control-Max-Age：浏览器可以将响应结果进行缓存的时间。

浏览器在接收到预检响应之后，会根据响应报头确定后续发送的真正跨域资源请求是否会被接受，相关的检验包括针对服务端允许站点以及HTTP方法和自定义请求报头（利用响应报头“Access-Control-Allow-Methods”和“Access-Control-Allow-Headers”）的检验。具体的检验逻辑如下

1. 通过请求的“Origin”报头表示的源站点必须存在于“Access-Control-Allow-Origin”响应报头标识的站点列表中。
2. 响应报头“Access-Control-Allow-Methods”不存在，或者预检请求的“Access-Control-Request-Method”报头表示的请求方法在其列表之内。
3. 预检请求的“Access-Control-Request-Headers”报头存储的报头名称均在响应报头“Access-Control-Allow-Headers”表示的报头列表之内。

只有在确定服务端一定会接受的情况下，浏览器才会发送真正跨域资源请求。预检响应结果会被浏览器缓存，在“Access-Control-Max-Age”报头设定的时间内，缓存的结果将被浏览器用户进行授权检验，所以在此期间不会再有预检请求发送。

用户凭证

在默认情况下，利用XMLHttpReuqest发送的Ajax请求不会携带用户凭证相关的敏感信息，这里的用户凭证类型包括Cookie、HTTP-Authentication报头以及客户端X.509证书（采用支持客户端证书的TLS/SSL）等。如果需要用户凭证附加到Ajax请求上，需要将XMLHttpReuqest的withCredentials 属性设置为True。

W3C的CORS规范，服务端利用响应报头“Access-Control-Allow-Credentials”来表明自身是否支持用户凭证。

JavaScript程序利用一个withCredentials属性为true的XMLHttpReuqest发送了一个跨域资源请求，但是浏览器得到的响应中不具有一个值为“true”的响应报头“Access-Control-Allow-Credentials”，它对获取资源的操作将会浏览器拒绝。

ps:本文参考摘要《ASP.NET Web API 2框架揭秘》一书