ASP.NET Web API 2 对 CORS 的支持

跨域资源共享 (CORS) 是一种万维网联合会 (W3C) 规范(通常被认为是 HTML5 的一部分),它可让 JavaScript 克服由浏览器施加的同域策略安全限制。所谓同域策略,就是 JavaScript 只能对包含网页的同 一个域进行 AJAX 回调(其中,“域”就是主机名、协议和端口号的组合)。例如, http://foo.com 中某个网页上的 JavaScript 无法对 http://bar.com(或 http://www.foo.com、 https://foo.com 或 http://foo.com:999 等)进行 AJAX 调用。

CORS 可让服务器指明允许哪些域对它们进行调用,从而放宽这种限制。CORS 是由浏览器强制执行的,并 且必须在服务器上实现,而最新版本的 ASP.NET Web API 2 全面支持 CORS。通过 Web API 2,您可以对策略 进行配置以允许不同域的 JavaScript 客户端访问您的 API。

CORS 基本信息

由于 Web API 完全按照该规范来实现,因此,为了使用 Web API 中的新 CORS 功能,详细了解 CORS 本 身将大有帮助。这些详细内容现在看起来可能都是理论之谈,但对于以后了解 Web API 中的可用设置来说将 十分有用:在您调试 CORS 时,这些内容有助于您更快速地解决问题。

CORS 的一般机制是,当 JavaScript 尝试进行跨域 AJAX 调用时,浏览器会通过在 HTTP 请求中发送标头 (如“Origin”)来“询问”服务器是否允许进行这样的调用。服务器通过在响应中返 回 HTTP 标头(如“Access-Control-Allow-Origin”)指明允许的操作。这种权限检查将针对客 户端调用的每个不同 URL 进行,这就意味着不同的 URL 可以具有不同权限。

除域之外,CORS 还可以让服务器指明允许使用的 HTTP 方法、客户端可以发送的 HTTP 请求标头、客户端 可以读取的 HTTP 响应标头以及是否允许浏览器自动发送或接收凭据(Cookie 或授权标头)。其他请求和响 应标头指明允许使用其中的哪些功能。图 1 总结了这些标头(请注意,一些功能没有在响 应中发送的标头,仅有响应)。

图 1 CORS HTTP 标头

浏览器可通过两种不同的方式向服务器请求这些权限:简单 CORS 请求和预检 CORS 请求。

简单 CORS 请求。下面是简单 CORS 请求的示例:

POST http://localhost/WebApiCorsServer/Resources/ HTTP/1.1

Host: localhost

Accept: */*

Origin: http://localhost:55912

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

value1=foo&value2=5

响应如下:

HTTP/1.1 200 OK

Content-Type: application/json; charset=utf-8

Access-Control-Allow-Origin: http://localhost:55912

Content-Length: 27

{"Value1":"foo","Value2":5}

该请求是从 http://localhost:55912 到 http://localhost 的跨域请求,而浏览器会在该请求中添加一 个“Origin”HTTP 标头以指示服务器的调用域。 服务器用“Access-­Control-Allow- Origin”响应标头进行响应,指明允许使用此域。 浏览器强制执行服务器的策略,而 JavaScript 将接 收其正常成功回调。

服务器或者可以使用来自该请求的确切域值做出响应,或者可以使用指明允许使用任何域的 “*”值做出响应。 如果服务器还未允许该调用域,则“Access-Control-Allow- Origin”标头会缺失,并会引起该调用 JavaScript 的错误回调。

请注意,进行简单 CORS 请求时,仍会对服务器进行调用。 如果您对 CORS 了解不深,可能会觉得奇怪, 但这种行为无异于浏览器已构造 <form> 元素并进行正常 POST 请求的情况。 CORS 不会阻止对服务器 的调用;但它会阻止调用 JavaScript 接收结果。 如果您要阻止调用方调用服务器,则需要在服务器代码中 实现某种授权(可能要使用 [Authorize] 授权筛选器属性)。

前面的示例称为简单 CORS 请求,因为来自客户端的 AJAX 调用的类型或者是 GET,或者是 POST; Content-Type 是 application/x-www-form-­urlencoded、multipart/form-data 或 text/plain 中的一 个;未发送任何其他请求标头。 如果 AJAX 调用是另一个 HTTP 方法,Content-Type 是某个其他值,或者客 户端想要发送其他请求标头,则会将该请求视为预检请求。 预检请求的机制略有不同。

预检 CORS 请求。如果 AJAX 调用不是简单请求,则它需要一个预检 CORS 请求,此请求只不过是一个发 送到服务器以获取权限的附加 HTTP 请求。 此预检请求由浏览器自动发出,并使用 OPTIONS HTTP 方法。 如 果服务器成功响应该预检请求并授予权限,则浏览器将执行 JavaScript 正在尝试执行的实际 AJAX 调用。

如果关心的是性能问题(以及何时出现性能问题),则浏览器可通过在预检响应中包含 Access-Control- Max-Age 标头来缓存此预检请求的结果。 该值包含可对权限进行缓存的秒数。

时间: 2024-08-21 13:35:33

ASP.NET Web API 2 对 CORS 的支持的相关文章

ASP.NET Web API自身对CORS的支持: CORS授权检验的实施

通过<EnableCorsAttribute特性背后的故事>我们知道:由CorsPolicyProvider提供的CorsPolicy表示目标Action采用的资源授权策略,ASP.NET Web API最终需要利用它对具体的跨域资源请求实施授权检验并生成相应的CORS响应报头.在ASP.NET Web API的应用编程接口中,资源授权检验的结果通过类型CorsResult来表示. 一.CorsResult CorsResult定义在命名空间"System.Web.Cors"

ASP.NET Web API自身对CORS的支持:从实例开始

在<通过扩展让ASP.NET Web API支持W3C的CORS规范>中我们通过自定义的HttpMessageHandler为ASP.NET Web API赋予了跨域资源共享的能力,具体来讲,这个自定义的CorsMessageHandler的自由主要体现在如下两个方面:其一,为简单跨域请求的响应和继预检请求后的真实跨域资源请求的响应添加CORS报头:其二,对从浏览器发送的预检请求予以响应.实际上ASP.NET Web API本身就提供了针对CORS的支持,就其实现原理来看,与我们的实现没有本质

ASP.NET Web API自身对CORS的支持: EnableCorsAttribute特性背后的故事

从编程的角度来讲,ASP.NET Web API针对CORS的实现仅仅涉及到HttpConfiguration的扩展方法EnableCors和EnableCorsAttribute特性.但是整个CORS体系不限于此,在它们背后隐藏着一系列的类型,我们将会利用本章余下的内容对此作全面讲述,今天我们就来讨论一下用于定义CORS授权策略的EnableCorsAttribute特性背后的故事. 目录 一.CorsPolicy 二.CorsPolicyProvider 三.CorsPolicyProvid

Web API 2 对 CORS 的支持

原文:Web API 2 对 CORS 的支持 Web API 2 对 CORS 的支持 CORS概念 跨域资源共享 (CORS) 是一种万维网联合会 (W3C) 规范(通常被认为是 HTML5 的一部分),它可让 JavaScript 克服由浏览器施加的同域策略安全限制. 所谓同域策略,就是 JavaScript 只能对包含网页的同一个域进行 AJAX 回调(其中,"域"就是主机名.协议和端口号的组合). 例如,http://foo.com 中某个网页上的 JavaScript 无法

JavaScript跨域调用、JSONP、CORS与ASP.NET Web API[共8篇]

[第1篇] 同源策略与JSONP 浏览器是访问Internet的工具,也是客户端应用的宿主,它为客户端应用提供一个寄宿和运行的环境.而这里所说的应用,基本是指在浏览器中执行的客户端JavaScript程序.虽然是一种解释性的脚本语言,JavaScript其实是无比强大的,原则上来讲它可以做任何事.但是在能够在JavaScript脚本并不都是值得信赖的,所以浏览器必须对JavaScript的执行作相应的限制,这就是"同源策略(Same Origin Policy)".JavaScript

通过扩展让ASP.NET Web API支持W3C的CORS规范

让ASP.NET Web API支持JSONP和W3C的CORS规范是解决"跨域资源共享"的两种途径,在<通过扩展让ASP.NET Web API支持JSONP>中我们实现了前者,并且在<W3C的CORS Specification>一文中我们对W3C的CORS规范进行了详细介绍,现在我们通过一个具体的实例来演示如何利用ASP.NET Web API具有的扩展点来实现针对CORS的支持. 目录 一.ActionFilter OR HttpMessageHandl

通过扩展让ASP.NET Web API支持JSONP

同源策略(Same Origin Policy)的存在导致了"源"自A的脚本只能操作"同源"页面的DOM,"跨源"操作来源于B的页面将会被拒绝.同源策略以及跨域资源共享在大部分情况下针对的是Ajax请求.同源策略主要限制了通过XMLHttpRequest实现的Ajax请求,如果请求的是一个"异源"地址,浏览器将不允许读取返回的内容.JSONP是一种常用的解决跨域资源共享的解决方案,现在我们利用ASP.NET Web API自身

【ASP.NET Web API教程】2.1 创建支持CRUD操作的Web API

原文 [ASP.NET Web API教程]2.1 创建支持CRUD操作的Web API 2.1 Creating a Web API that Supports CRUD Operations2.1 创建支持CRUD操作的Web API By Mike Wasson | January 28, 2012作者:Mike Wasson | 日期:2012-1-28 本文引自:http://www.asp.net/web-api/overview/creating-web-apis/creating

支持Ajax跨域访问ASP.NET Web Api 2(Cors)的示例教程_实用技巧

随着深入使用ASP.NET Web Api,我们可能会在项目中考虑将前端的业务分得更细.比如前端项目使用Angularjs的框架来做UI,而数据则由另一个Web Api 的网站项目来支撑.注意,这里是两个Web网站项目了,前端项目主要负责界面的呈现和一些前端的相应业务逻辑处理,而Web Api则负责提供数据. 这样问题就来了,如果前端通过ajax访问Web Api项目话,就涉及到跨域了.我们知道,如果直接访问,正常情况下Web Api是不允许这样做的,这涉及到安全问题.所以,今天我们这篇文章的主