如何从服务器端启用CORS?

时间:2017-08-22 01:01:16

标签: asp.net asp.net-web-api browser cors same-origin-policy

根据我在Web API方面的经验,相同的原始策略是浏览器的策略,即浏览器不允许向其他主机而不是源发出请求。我想知道如何从服务器端启用CORS(谈论ASP.net Web API)?

这是我在webAPI中启用CORS的方式

namespace WebService.Controllers
{
    [EnableCors(origins: "*", headers: "*", methods: "*")]
    public class TestController : ApiController
    {
        // Controller methods ...
    }
}

如果CORS是浏览器,那么从客户端启用它是不合逻辑的。任何人都可以清楚这一点

1 个答案:

答案 0 :(得分:2)

以下是对其工作原理的简短总结的尝试:浏览器是强制执行同源策略和跨源限制的地方。具体来说,浏览器阻止前端JavaScript代码访问来自跨源请求的响应 - ,除非服务器发出请求以在响应中发送响应头Access-Control-Allow-Origin

换句话说,让浏览器放松同源策略的方法是服务器使用Access-Control-Allow-Origin标头来表明他们选择了跨源请求。

因此,浏览器是应用或放宽任何跨源限制的地方。

有助于说明其工作原理的一个案例是一个简单的跨源POST。只要跨域POST没有任何自定义请求标头会触发浏览器执行CORS preflight OPTIONS request,浏览器就会继续发出请求,甚至是跨域请求。 POST发送到的服务器将继续接受并发送响应。

然后会发生什么情况是来自浏览器的跨域限制的地方 - 因为如果POST请求是使用XHR从前端JavaScript代码发送的,或者是来自某些JavaScript库的Fetch API或Ajax方法,那么除非响应包括Access-Control-Allow-Origin标头,浏览器不允许前端代码访问响应(即使服务器接受了POST并且它成功了。)

无论如何,我希望上述内容有助于澄清服务器中支持CORS实际意味着什么,以及它具有什么效果,以及实际的策略实施是由浏览器执行的。

当然,以上所有内容都只描述了最简单的情况,其中没有请求的特征会触发浏览器执行CORS preflight OPTIONS request

但在这种情况下,策略执行全部由浏览器执行 - 事实上更是如此,例如,浏览器不允许将带有自定义标头的POST发送到除非服务器明确指出(在对预检OPTIONS的响应中)服务器已选择接收包含该自定义标头的跨源请求,否则服务器开始。