.Net Core Cors中间件的深入讲解

同源策略和资源跨域共享

1、同源策略

同源策略,它是由Netscape提出的一个著名的安全策略。现在所有支持JavaScript 的浏览器都会使用这个策略。所谓同源是指,域名,协议,端口相同。

1.1、目的

主要是为了保证用户信息的安全,防止网站窃取用户数据。假如没有同源策略,可能就会有下面这种情况的发生。用户访问两个网站A/B,并登录了A网站,A网站会在计算机本地存储Cookie或者Token等等,在访问B网站的时候,B网站就可以访问这些本地的存储信息,B网站可以使用用户的Cookie去登录A网站,那这样用户信息就被泄露了。

1.2、限制范围   

  • Cookie、LocalStorage和indexDB无法访问(只有同源的网页才能共享Cookie)
  • DOM无法获得(父窗口和子窗口的地址是同源的才能获取子窗口的信息)
  • AJAX请求不能被发送(AJAX请求只能发送给同源的网址)

要知道一点,这些限制其实都是浏览器做的限制。

2、跨域资源共享

跨域资源共享跟同源策略相反。在整个跨域通信过程中,浏览器会自动识别此次请求是否跨域,一旦发现跨域,就自动添加请求头信息(如Origin)或者自动发送一次请求方式为option的预请求。浏览器将CORS请求分为两类:简单请求和非简单请求。

2.1、简单请求

当浏览器的请求方式是Head、Get或者Post,并且HTTP的头信息中不会超出以下字段:

  • Accept
  • Accept-Language
  • Content-Language
  • Origin

时,浏览器会将该请求定义为简单请求,否则就是非简单请求。当浏览器判断为简单请求后,浏览器会自动再请求报文头中加上Origin字段,表明此次请求来自的地址(协议+域名+端口)。然后服务器需要去判断是否接受这个来源的请求。如果允许服务器端返回的头部中需要有Access-Control-Allow-Origin,其值为请求时Origin字段的值或*(表示接受任意源的请求)。请求头中还会有Access-Control-Allow-Methods表示服务器允许的跨域请求的方式。Access-Control-Allow-Headers表示请求头中允许出现的字段。

2.2、 非简单请求

当浏览器判断为非简单请求后,会发送两次请求,首先浏览器会自动发送一个请求方式为options的请求,并在请求头中

  • 加上Access-Control-Request-Method表示下次请求的方法,
  • 加上Origin表明来源,
  • 加上Access-Control-Request-Headers表示下次请求的请求头中额外的字段。

服务器收到请求后,需要获取这三个请求头中的值,并进行判断,确认是否允许进行跨域。如果服务器返回的请求头中没有任何CORS相关的请求头信息,浏览器会认为不通过预检,也不会进行第二次请求。

服务器如果接受跨域并验证通过了options的请求,会返回Access-Control-Allow-Origin(表明允许跨域请求的源)、Access-Control-Allow-Methods(允许跨域请求的请求方式)、Access-Control-Allow-Headers(允许请求头中包含的额外字段)。然后浏览器才会发送真正的请求。 

                 

(第一次options请求)

(第二次请求)

二、服务端实现CORS

在.Net Core Web Api中使用很简单,首先安装包Microsoft.AspNet.WebApi.Cors,在StartUp中添加下面两句

public void ConfigureServices(IServiceCollection services)
 {
  services.AddMvc();
       //添加Cors,并配置CorsPolicy
  services.AddCors(options => options.AddPolicy("CorsTest", p => p.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod()));
 }

 public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
 {
  if (env.IsDevelopment())
  {
  app.UseDeveloperExceptionPage();
  }       //注意UseCors()要在UseMvc()之前
  app.UseCors("CorsTest");
  app.UseMvc();
 }

在使用的时候只需要在Controller或者Action中加上特性[EnableCors("CorsTest")]

[EnableCors("CorsTest")]
 public class ValuesController : Controller
 {
 private ILogger<ValuesController> _logger;
 public ValuesController(ILogger<ValuesController> logger)
 {
  _logger = logger;
 }
 [HttpGet]
 public IEnumerable<string> Get()
 {
  return new string[] { "value1", "value2" };
 }
 }

现在服务端已经配置好了,现在需要通过前端跨域请求

<html>
<head>
 测试
</head>
<body>
 测试
</body>
</html>
<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>
<script type="text/javascript">
 $(function () {
 $.ajax({
  type: "get",
  url: "http://localhost:7000/api/values",
  beforeSend: function (request) {//在请求报文头中加入Authorization 目的是让请求为非简单请求
  request.setRequestHeader("Authorization", "Bearer 071899A00D4D4C5B1C41A6B0211B9399");
  },
  success: function (result) {
  alert(result);
  }
 }, "json");
 });
</script>

测试结果如下图:

                          (options请求)

                        (第二次请求)

上面配置允许所有的地址请求这个接口,也可以单独配置某个地址。

services.AddCors(options => options.AddPolicy("CorsTest", p => p.WithOrigins("http://localhost:8089")
                   .AllowAnyHeader()
                   .AllowAnyMethod()));

 三、解析Cors源码

打开CORS源码,主要的是CorsMiddleware、CorsOptions、CorsPolicy、CorsPolicyBuilder、CorsResult、CorsService这几个类。

  • CorsPolicy:就是我们在Startup中的配置,如允许哪些域名可以跨域请求,允许哪些跨域请求方式,允许哪些额外的请求头,每个配置对应一个名称。
           services.AddCors(options => options.AddPolicy("CorsTest", p => p.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod()));
  • CorsOptions:中包含一个字典IDictionary<string, CorsPolicy> PolicyMap,一个项目可能有过个Cors配置,所以这个CorsOptions就是通过配置名称管理这些配置的。
  • CorsPolicyBuilder:通过它来构造CorsPolicy。
  • CorsResult:是验证跨域过程得到的结果。如在第一次Options请求时,客户端发送了Origi:http://localhost:8089,服务器会返回Access-Control-Allow-Origin:http://localhost:8089,服务器验证http://localhost:8089这个域名是否允许跨域,如果允许就将“http://localhost:8089”这个值存储到CorsResult的AllowedHeaders中,在请求(第一次请求)返回的时候将这些加到HTTP请求头中。
  • CorsMiddleware:Cors中间件类,主要方法就是Invoke,每次HTTP请求都会调用这个方法。
public async Task Invoke(HttpContext context)
  {//判断HTTP请求头是否有Origin,由此判断是不是跨域请求
   if (context.Request.Headers.ContainsKey(CorsConstants.Origin))
   {
    var corsPolicy = _policy ?? await _corsPolicyProvider?.GetPolicyAsync(context, _corsPolicyName);
    if (corsPolicy != null)
    {
     var accessControlRequestMethod = context.Request.Headers[CorsConstants.AccessControlRequestMethod];            //如果是跨域请求 判断是不是第一次Options请求
     if (string.Equals(context.Request.Method,CorsConstants.PreflightHttpMethod,StringComparison.OrdinalIgnoreCase)
      &&!StringValues.IsNullOrEmpty(accessControlRequestMethod))
     {               //判断是否允许当前请求跨域,根据HttpContext的内容和Cors配置 得到CorsResult,然后将CorsResult的内容添加到请求头中(看下面详细解释)
      ApplyCorsHeaders(context, corsPolicy);
      context.Response.StatusCode = StatusCodes.Status204NoContent;
      return;
     }
     else
     {// 执行第二次非Options请求
      context.Response.OnStarting(state =>
      {
       var (httpContext, policy) = (Tuple<HttpContext, CorsPolicy>)state;
       try
       {
        ApplyCorsHeaders(httpContext, policy);
       }
       catch (Exception exception)
       {
        _logger.FailedToSetCorsHeaders(exception);
       }
       return Task.CompletedTask;
      }, Tuple.Create(context, corsPolicy));
     }
    }
   }
   await _next(context);
  }
    
  private void ApplyCorsHeaders(HttpContext context, CorsPolicy corsPolicy)
  {  //通过HTTP上下文请求的数据和Cors配置 得到CorsResult        如在第一次Options请求时,客户端发送了Origi:http://localhost:8089,Access-Control-Resquest-Methods:GET        服务器会返回Access-Control-Allow-Origin:http://localhost:8089,Access-Control-Allow-Methods:GET        服务器验证http://localhost:8089这个域名以GET请求方式是否允许跨域,        如果允许就将“http://localhost:8089”这个值存储到CorsResult的AllowedHeaders中        将"GET"存储到CorsResult的AllowedMethods中
   var corsResult = _corsService.EvaluatePolicy(context, corsPolicy);        //将CorsResult中的值添加到相应头中的,返回到客户端
   _corsService.ApplyResult(corsResult, context.Response);
  }

相对来说Cors源码还是比较简单的,很容易看懂。可以自己写一个项目,然后挂上源码单步调试。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对我们的支持。

(0)

相关推荐

  • 利用.net core实现反向代理中间件的方法

    最近在将一些项目的rest api迁移到.net core中,最开始是用的Nginx做反向代理,将已经完成切换的部分切入系统,如下图所示: 由于迁移过程中也在进行代码重构,需要经常比较频繁的测试,以保证能及时发现引入的问题.从而导致我们每迁移一部分都需要配置一次nginx的路由映射,保证迁移的功能能切入系统测试. 进行了一段时间后,发现经常配置Nginx一来比较麻烦,二来容易配错:便想将这个反向代理的功能放在.net core程序中去,实现如下的功能: Rest请求直接发往.net core程序

  • Asp.Net Core 通过中间件防止图片盗链的实例

    一.原理 要实现防盗链,我们就必须先理解盗链的实现原理,提到防盗链的实现原理就不得不从HTTP协议说起,在HTTP协议中,有一个表头字段叫referer,采用URL的格式来表示从哪儿链接到当前的网页或文件.换句话说,通过referer,网站可以检测目标网页访问的来源网页,如果是资源文件,则可以跟踪到显示它的网页地址.有了referer跟踪来源就好办了,这时就可以通过技术手段来进行处理,一旦检测到来源不是本站即进行阻止或者返回指定的页面.如果想对自己的网站进行防盗链保护,则需要针对不同的情况进行区

  • .Net Core中间件之静态文件(StaticFiles)示例详解

    一.介绍 静态文件(static files),诸如 HTML.CSS.图片和 JavaScript 之类的资源会被 ASP.NET Core 应用直接提供给客户端. 在介绍静态文件中间件之前,先介绍 ContentRoot和WebRoot概念. ContentRoot:指web的项目的文件夹,包括bin和webroot文件夹. WebRoot:一般指ContentRoot路径下的wwwroot文件夹. 介绍这个两个概念是因为静态资源文件一般存放在WebRoot路径下,也就是wwwroot.下面

  • 详解在ASP.NET Core 中使用Cookie中间件

    在 http:// ASP.NET Core 中使用Cookie中间件 ASP.NET Core 提供了Cookie中间件来序列化用户主题到一个加密的Cookie中并且在后来的请求中校验这个Cookie,再现用户并且分配到HttpContext对象的User属性中.如果你想提供自己的登录方式和用户数据你可以使用Cookie中间件来实现独立的功能. 添加和配置 第一步是增加Cookie中间件到你的应用中.首先使用nuget增加Microsoft.AspNetCore.Authentication.

  • 浅谈ASP.NET Core中间件实现分布式 Session

    1.1. 中间件原理 1.1.1. 什么是中间件 中间件是段代码用于处理请求和响应,通常多个中间件链接起来形成管道,由每个中间件自己来决定是否要调用下一个中间件. 1.1.2. 中间件执行过程 举一个示例来演示中间件的执行过程(分别有三个中间件:日志记录.权限验证和路由):当请求进入应用程序时,执行执行日志记录的中间件,它记录请求属性并调用链中的下一个中间件权限验证,如果权限验证通过则将控制权传递给下一个中间件,不通过则设置401 HTTP代码并返回响应,响应传递给日志中间件进行返回. 1.1.

  • ASP.NET Core 2.0 带初始参数的中间件问题及解决方法

    问题 如何在ASP.NET Core 2.0向中间件传入初始参数? 答案 在一个空项目中,创建一个POCO(Plain Old CLR Object)来保存中间件所需的参数: public class GreetingOptions { public string GreetAt { get; set; } public string GreetTo { get; set; } } 添加一个中间件: public class GreetingMiddleware { private readon

  • 浅谈ASP.NET Core 中间件详解及项目实战

    前言 本篇文章是我们在开发自己的项目中实际使用的,比较贴合实际应用,算是对中间件的一个深入使用了,不是简单的Hello World. 中间件(Middleware)的作用 我们知道,任何的一个web框架都是把http请求封装成一个管道,每一次的请求都是经过管道的一系列操作,最终到达我们写的代码中.那么中间件就是在应用程序管道中的一个组件,用来拦截请求过程进行一些其他处理和响应.中间件可以有很多个,每一个中间件都可以对管道中的请求进行拦截,它可以决定是否将请求转移给下一个中间件. asp.net

  • 详解ASP.NET Core 中间件之压缩、缓存

    前言 今天给大家介绍一下在 ASP.NET Core 日常开发中用的比较多的两个中间件,它们都是出自于微软的 ASP.NET 团队,他们分别是Microsoft.AspNetCore.ResponseCompression 和 Microsoft.AspNetCore.ResponseCaching , 下面让我们一起看看的功能以及如何去使用吧. Getting Started Microsoft.AspNetCore.ResponseCompression Microsoft.AspNetCo

  • .Net Core Cors中间件的深入讲解

    同源策略和资源跨域共享 1.同源策略 同源策略,它是由Netscape提出的一个著名的安全策略.现在所有支持JavaScript 的浏览器都会使用这个策略.所谓同源是指,域名,协议,端口相同. 1.1.目的 主要是为了保证用户信息的安全,防止网站窃取用户数据.假如没有同源策略,可能就会有下面这种情况的发生.用户访问两个网站A/B,并登录了A网站,A网站会在计算机本地存储Cookie或者Token等等,在访问B网站的时候,B网站就可以访问这些本地的存储信息,B网站可以使用用户的Cookie去登录A

  • 在 asp.net core 的中间件中返回具体的页面的实现方法

    前言 在 asp.net core 中,存在着中间件这一概念,在中间件中,我们可以比过滤器更早的介入到 http 请求管道,从而实现对每一次的 http 请求.响应做切面处理,从而实现一些特殊的功能 在使用中间件时,我们经常实现的是鉴权.请求日志记录.全局异常处理等等这种非业务性的需求,而如果你有在 asp.net core 中使用过 swashbuckle(swagger).health check.mini profiler 等等这样的组件的话,你会发现,这些第三方的组件往往都提供了页面,允

  • ASP.NET Core自定义中间件如何读取Request.Body与Response.Body的内容详解

    背景# 最近在徒手造轮子,编写一个ASP.NET Core的日志监控器,其中用到了自定义中间件读取Request.Body和Response.Body的内容,但是编写过程,并不像想象中的一帆风顺,ASP.NET Core针对Request.Body和Response.Body的几个特殊设计,导致了完成以上功能需要绕一些弯路. 原始代码# 为了读取Request.Body和Response.Body的内容,我的实现思路如下: 创建一个LoggerMiddleware的中间件,将它放置在项目中间件管

  • .net core静态中间件的使用

    目录 结 正文 我们使用静态文件调用: app.UseStaticFiles(); 那么这个默认会将我们根目录下的wwwroot作为静态目录. 这个就比较值得注意的,可能刚开始学.net core 的小伙伴,会直接把脚本写在更目录script这样是访问不到的. 当然了,你可以配置参数.可以给UseStaticFiles传递参数.不过建议不要这么干,因为这是一种默认的约定. 在wwwroot下建立一个index.html,那么访问http://localhost/index.html <!DOCT

  • .net core异常中间件的使用

    目录 正文 正文 if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } 这样写入中间件哈,那么在env环境下就会去执行UseDeveloperExceptionPage. public static IApplicationBuilder UseDeveloperExceptionPage(this IApplicationBuilder app) { if (app == null) { throw new Argument

  • ASP.NET Core基础之Main方法讲解

    为什么ASP.NET Core采用Main方法? 需要记住的最重要的一点是,ASP.NET Core Web 应用程序最初作为控制台应用程序启动,Main() 方法是应用程序的入口点.因此,当我们执行ASP.NET Core Web应用程序时,首先它寻找 Main() 方法,这是执行开始的方法.然后,Main()方法将ASP.NET配置并启动它.此时,应用程序将成为ASP.NET Core Web应用程序. 如果进一步查看 Main() 方法的正文,则会发现它通过将命令行参数 args 作为参数

  • ASP.NET Core自定义中间件的方式详解

    目录 1.委托形式 2.强类型中间件 2.1.定义中间件的依赖 2.2.定义中间件类型 3.基于约定的中间件 3.1.约定规则 3.2.应用实现 总结 ASP.NET Core应用本质上,其实就是由若干个中间件构建成的请求处理管道.管道相当于一个故事的框架,而中间件就相当于故事中的某些情节.同一个故事框架采用不同的情节拼凑,最终会体现出不同风格的故事.而我们的ASP.NET Core应用也正是如此,同一管道采用不同的中间件组合,最终也会呈现出不同的应用形态. 从上述的概念种可以看出,中间件在AS

  • NodeJs Express中间件超详细讲解

    目录 什么是中间件 现实生活中的例子 Express 中间件的调用流程 Express 中间件的格式 next 函数的作用 定义中间件函数 全局生效的中间件 定义全局中间件的简化形式 中间件的作用 定义多个全局中间件 局部生效的中间件 定义多个局部中间件 了解中间件的5个使用注意事项 中间件的分类 应用级别的中间件 路由级别的中间件 错误级别的中间件 Express内置的中间件 第三方的中间件 自定义中间件 1. 需求描述与实现步骤 2. 定义中间件 3 .监听req的data事件 4. 监听r

  • ASP.NET Core的中间件与管道介绍

    今天来讨论一个ASP.NET Core 很重要概念管道和中间件,在ASP.NET Core中,针对HTTP请求采用pipeline也就是通常说的管道方式来处理,而管道容器内可以挂载很多中间件(处理逻辑)“串联”来处理HTTP请求,每一个中间件都有权决定是否需要执行下一个中间件,或者直接做出响应.这样的机制使得HTTP请求能够很好的被层层处理和控制,并且层次清晰处理起来甚是方便. 示意图如下: 为了再次说明管道和中间件的概念,举一个官方给出的权限验证的例子,中间件A,B分别按顺序挂载在管道容器中,

随机推荐