从编程的角度来讲，ASP.NET Web API针对CORS的实现仅仅涉及到HttpConfiguration的扩展方法EnableCors和EnableCorsAttribute特性。但是整个CORS体系不限于此，在它们背后隐藏着一系列的类型，我们将会利用本章余下的内容对此作全面讲述，今天我们就来讨论一下用于定义CORS授权策略的EnableCorsAttribute特性背后的故事。 目录 一、CorsPolicy 二、CorsPolicyProvider 三、CorsPoli
ASP.NET MVC应用的请求都是针对某个Controller的某个Action方法，所以对请求的处理最终体现在对目标Action方法的执行。而Action方法具有相应的参数，所以在方法执行之前必须根据相应的规则从请求中提取相应的数据并将其转换为Action方法参数列表，我们将这个过程称为Model绑定。在ASP.NET MVC应用编程接口中，Action方法某个参数的元数据通过ParameterDescriptor表示，而两个相关的类型ControllerDescriptor和ActionDescrip
通过《EnableCorsAttribute特性背后的故事》我们知道：由CorsPolicyProvider提供的CorsPolicy表示目标Action采用的资源授权策略，ASP.NET Web API最终需要利用它对具体的跨域资源请求实施授权检验并生成相应的CORS响应报头。在ASP.NET Web API的应用编程接口中，资源授权检验的结果通过类型CorsResult来表示。 一、CorsResult CorsResult定义在命名空间“System.Web.Cors”下，表示资源提供者针对具体跨域资
Model绑定是为作为目标Action的方法准备参数列表的过程，所以针对参数的描述才是Model绑定的核心。在ASP.NET MVC应用编程接口中，服务于Model绑定的参数元数据通过ParameterDescriptor类型来表示，而ActionDescriptor的GetParameters方法返回的就是一个ParameterDescriptor数组。 如下面的代码片断所示，ParameterDescriptor同样实现了ICustomAttributeProvider接口提供应用在相应参数上的特性。P
在ASP.NET Model绑定系统中，用于提供数据值的ValueProvider对象通过ValueProviderFactory来创建。在ASP.NET MVC应用编程接口中，ValueProviderFactory继承自ValueProviderFactory类。本篇文章只要介绍基于ValueProviderFactory的ValueProvider的提供机制，以及如何通过自定义ValueProviderFactory实现我们需要的数据值的绑定方式。[本文已经同步到《How ASP.NET MVC Wo
旨在为目标Action方法的执行绑定输入参数的Model绑定过程伴随着对Model的验证。借助相应的验证特性，我们可以直接以声明的方式在Model类型上定义验证规则，这些规则将会作为Model元数据的一部分。具体在Model绑定过程中，ModelBinder通过ValueProvider为Model对象的某个属性提供相应属性值之后，会根据定义在基于该属性的Model元数据的验证规则实施验证。ASP.NET MVC的整个Model验证系统以组件ModelValidator为核心，或者说Model对象的验证最终
开篇：ASP.Net是一项动态网页开发技术，在历史发展的长河中WebForm曾一时成为了ASP.Net的代名词，而ASP.Net MVC的出现让这项技术更加唤发朝气。但是，不管是ASP.Net WebForm还是ASP.Net MVC在请求处理机制上大部分都是相同的，只是在请求处理管道上的处理事件做了不同的操作，因此，本文标题不区分ASP.Net WebForm和ASP.Net MVC，但在后续的介绍中会区分开来介绍。此外，本文以IIS经典模式为主，不讨论集成模式（IIS7后加入了集成模式，不用加载外部的aspnet_isapi.dll组件）。
虽然ASP.NET Web API框架采用与ASP.NET MVC框架类似的管道式设计，但是ASP.NET Web API管道的核心部分（定义在程序集System.Web.Http.dll中）已经移除了对System.Web.dll程序集的依赖，实现在ASP.NET Web API框架中的URL路由系统亦是如此。也就是说，ASP.NET Web API核心框架的URL路由系统与ASP.NET本身的路由系统是相对独立的。但是当我们采用基于Web Host的方式（定义在程序集System.Web.Http.We
关于ASP.NET MVC对请求的处理方式（同步或者异步）涉及到的五个组件，在《上篇》中我们谈了三个（MvcHandler、Controller和ActionInvoker），现在我们来谈余下的两个，
前面的两篇文章（《从两个重要的概念谈起：Identity与Principal[上篇]》和《从两个重要的概念谈起：Identity与Principal[下篇]》）主要探讨基于安全主体的授权。通过这些介绍我们知道：如果我们在实施授权的时候，当前线程的安全主体能够被正确设置，我们就可以正确地完成授权。基于相同的原理，对于WCF的服务授权，如果正确的安全主体能够在服务操作被执行之前被正确设置到当前线程，借助于这个安全主体，我们不但可以采用命令式编程的方式将授权逻辑写在相应的操作中，也可以采用声明式编程的方式将授权策
总的来说，我们可以通过RouteTable的静态属性Routes得到一个基于应用的全局路由表，通过上面的介绍我们知道这是一个类型的RouteCollection的集合对象，我们可以通过调用它的MapPageRoute进行路由映射，即注册URL模板与某个物理文件的匹配关系。路由注册的核心就是在全局路由表中添加一个Route对象，该对象的绝大部分属性都可以通过MapPageRoute方法的相关参数来指定。接下来我们通过实现演示的方式来说明路由注册的一些细节问题。 目录 一、变量默认值
我们上网时，在浏览器地址输入网址，按下回车，一张网页就呈现在我们眼前。这究竟发生了什么？对于一名优秀的Programmer来说，我想有必要一下熟悉浏览器--->服务器请求的过程。 ASP.NET ASP.NET是运行在公共语言运行时刻时（CLR）上的应用程序框架。他用来在服务器端构建功能强大的web应用程序。当浏览器请求 ASP.NET 文件时，IIS 会把该请求传递给服务器上的 ASP.NET 引擎，ASP.NET 引擎会逐行地读取该文件，并执行文件中的脚本，最后，ASP.NET 文件会以纯 HT
作为《ASP.NET Core 3框架揭秘》的升级版，《ASP.NET Core 6框架揭秘》提供了很多新的章节，同时对现有的内容进行大量的修改。虽然本书旨在对ASP.NET Core框架的架构设计和实现原理进行剖析，但是其中提供的258个实例演示却可以作为入门材料，这个系列会将这些演示实例单独提取出来并进行汇总。对于想学习ASP.NET Core的同学，如果你觉得没有必要“钻的这么深”，倒是可以看看。本篇提供的20个简单的演示实例基本涵盖了ASP.NET Core 6基本的编程模式，我们不仅会利用它们来演示针对控制台、API、MVC、gRPC应用的构建与编程，还会演示Dapr在.NET 6中的应用。除此之外，这20个实例还涵盖了针对依赖注入、配置选项、日志记录的应用。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）
在进行Model绑定过程中，需要根据基于Action方法参数的绑定上下文从请求数据中提取相应的数据以提供相应的数据。具体来说，Model绑定的数据具有多个来源，可能来源于Post的表单或者JSON字符
在安全领域，认证和授权是两个重要的主题。认证是安全体系的第一道屏障，守护着整个应用或者服务的第一道大门。当访问者叩门请求进入的时候，认证体系通过验证对方提供凭证确定其真实身份。作为看门人的认证体系，只有在证实了访问者的真实身份的情况下才会为其打开城门，否则将之举之门外。 当访问者入门之后，并不意味着它可以为所欲为。为了让适合的人干适合的事，就需要授权机制为具体的人设置具体的权限，并根据这些权限设置决定试图调用的操作或者访问的资源对该访问者是否是安全的。对于一个安全保障体系来说，授权是目的。但是授权的执行是假
ASP.NET Core框架目前存在两个承载（Hosting）系统。ASP.NET Core最初提供了一个以IWebHostBuilder/IWebHost为核心的承载系统，其目的很单纯，就是通过下图所示的形式承载以服务器和中间件管道构建的Web应用。ASP.NET Core 3依然支持这样的应用承载方式，但是本系列不会涉及这种“过时”的承载方式。
从上面的内容我们知道ASP.NET Core请求处理管道由一个服务器和一组中间件构成，所以从总体设计来讲是非常简单的。但是就具体的实现来说，由于其中涉及很多对象的交互，很少人能够地把它弄清楚。如果想非常深刻地认识ASP.NET Core的请求处理管道，我觉得可以分两个步骤来进行：首先，我们可以在忽略具体细节的前提下搞清楚管道处理HTTP请求的总体流程；在对总体流程有了大致了解之后，我们再来补充这些刻意忽略的细节。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造
本文主要介绍了ASP.NET Web API的背景、使用方法和核心对象，包括HttpRequestMessage、HttpResponseMessage、HttpClient等，并分析了如何使用这些对象来处理HTTP请求和响应。
在微软Tech Summit 2017 大会上和大家分享了一门课程《.NET Core 在腾讯财付通的企业级应用开发实践》，其中重点是基于ASP.NET Core打造可扩展的高性能企业级API网关，以开源的API网关Ocelot为基础结合自己的业务特性，当天课程只有40分钟，有很多内容都没有展开，接下来就用一篇小文章来聊下Ocelot 的实现原理，大家在使用的过程中也可以一起来贡献。 总体来说这是一个ASP.NET Core 高级编程的内容，之前在公众号里已经发过不少各位朋友写的文章，今天都会在这篇文章中引
基于IHostBuilder/IHost的承载系统通过IHostEnvironment接口表示承载环境，我们利用它不仅可以得到当前部署环境的名称，还可以获知当前应用的名称和存放内容文件的根目录路径。对于一个Web应用来说，我们需要更多的承载环境信息，额外的信息定义在IWebHostEnvironment接口中。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
我经常听到 Microsoft 内部和外部的人将新的 IIS 7.0 Web 服务器称为 Microsoft 在过去几年中所进行的最重要的开发工作之一。考虑到 Microsoft 最近推出了一系列引人注意的技术，包括 Windows Vista™，这个评语具有重要意义！ IIS 7.0 的发布时间正好是 Windows NT® 4.0 中第一个 IIS 版本发布十周年的纪念日。2001 年，在四个版本之后，IIS 5.0 成为了 Internet 上最流行的 Web 服务器，尽管几个月后它成了臭名昭著的
学习是一个循序渐进的过程，作为一名.Net软件工程师我们需要学习和掌握的东西非常的多，本章主要是记录下前段时间面试中经常遇到的一些基础常识，这里只是大致的概括还有很多需要学习的东西需要不断的学习和积累。
在以前的ASP时候，当请求一个*.asp页面文件的时候，这个HTTP请求首先会被一个名为inetin网络
基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成，前者在《服务承载系统》已经有详细介绍，下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
第一次邂逅WCF是在微软举办的一场关于Windows Vista技术推广培训上，时间大概是2005年10月份，当时对WCF可谓是一见钟情。如果读者也像我一样，之前习惯了采用.NET Remoting、XML Web Service、WSE、MSMQ来架构你分布式应用的话，应该不难想象我第一次接触WCF时心中的那份震撼。WCF是Windows平台下所有分布式技术集大成者，它将这一系列独立的分布式技术整合，提供一个统一的应用编程接口，这本身就是一项创举。这些被整合的分布式技术不仅仅包含提到的这些，还包括DCOM
近几年互联网的一个发展重点是社交网站。Facebook、linkedin、开心网等这些社交网站在短时间内便聚集了巨量的用户数量、社交网络数据、应用数量和应用数据。在这些网站上，应用从设计之初就考虑了社交网络的存在。结果是优秀的应用和数据通过社交网络的病毒式传播得到更快的共享。开发人员从中得到启发，重新思考如何使用社交数据来重新设计应用，更好的实现协作；如何重新组织应用内容和数据，更好的分享；如何使用社交网络实现产品的营销等。越来越多的组织在考虑使用社交应用的形式来提供服务和数据。 OpenSocial 标准
dotnet 组织包含了.NET Core 的核心代码, 包括 coreclr 和 corefx 等.
Model的绑定体现在从当前请求提取相应的数据绑定到目标Action方法的参数。通过前面的介绍我们知道Action方法的参数通过ParameterDescriptor来描述，ParameterDescriptor的BindingInfo属性表示的ParameterBindingInfo对象具有一个名为ModelBinder的组件用于完成针对当前参数的Model绑定。ModelBinder可以看成是整个Model绑定系统的核心，我们先来认识这个重要的组件。[本文已经同步到《How ASP.NET MVC Wo
在Model绑定过程中会通过激活的Controller类型创建用于描述它的ControllerDescriptor对象。Controller是一组Action方法的集合，而每一个Action通过Act
我们知道ASP.NET Core请求处理管道由一个服务器和一组有序的中间件组成，所以从总体设计来讲是非常简单的，但是就具体的实现来说，由于其中涉及很多对象的交互，我想很少人能够地把它弄清楚。为了让读者朋友们能够更加容易地理解管道处理HTTP请求的总体流程，我们根据真实管道的实现原理再造了一个“模拟管道”并在此管道上开发了一个发布图片的应用，这篇文章旨在为你讲述管道是如何处理HTTP请求的 目录 一、HttpApplication FeatureCollection HostingAppli
在《ASP.NET MVC下的四种验证编程方式》一文中我们介绍了ASP.NET MVC支持的四种服务端验证的编程方式（“手工验证”、“标注ValidationAttribute特性”、“让数据类型实现IValidatableObject或者IDataErrorInfo”），那么在ASP.NET MVC框架内部是如何提供针对这四种不同编程方式的支持的呢？接下来我们就来聊聊这背后的故事。 一、ModelValidator与ModelValidatorProvider 虽然Model绑定的方式因被验证数据类型的差
通过《服务承载系统[2]: 承载长时间运行的服务[下篇]》的介绍可知，IHostBuilder接口中定义了ConfigureHostConfiguration方法和ConfigureAppConfiguration方法，它们可以帮助我们设置面向宿主（IHost对象）和应用（承载服务）的配置。针对配置的初始化也可以借助IWebHostBuilder接口来完成。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
一年前写了一篇短文ASP.NET MVC Action Filters，整理了Action Filter方面的资源，本篇文章详细的描述Action Filter。Action Filter作为一个可以应用到Controller Action（或者是整个controller）上的属性（Attribute），改变Action执行的行为，当应用于整个Controller上时，Controller上的所有Action都应用了同样设置的Action。 使用Action Filter 可以处理缓存、 验证和错误处理您的
当我们最开始学习一门技术的时候都喜欢从Hello World来时，貌似和我们本篇的主题不太搭。但事实却非如此，在我们看来如下这个Hello World是对ASP.NET Core框架本质最好的体现。
在2007年9月份，我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章，深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制，以及ASP.NET运行时管道对HTTP请求的处理流程： [原创]ASP.NET Process Model之一：IIS 和 ASP.NET ISAPI [原创]ASP.NET Process Model之二：ASP.NET Http Runtime Pipeline - Part I [原创]ASP.NET Process Model之二：ASP.N
.NET 7 预览版 1 现已推出！这是 .NET 下一个主要版本的第一个预览版，其中将包括使用 ASP.NET Core 进行 Web 开发的下一波创新。
我们先来看看IIS 5.x是如何处理基于ASP.NET资源（比如.aspx,.asmx等）请求的，整个过程基本上可以通过图1体现。
近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析（卷1）》的写作，一直无暇管理自己的Blog。在《WCF技术剖析（卷1）》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。 [第1篇] 通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我
原文地址：https://github.com/thangchung/awesome-dotnet-core
ASP.NET核心中间件组件是被组装到应用程序管道中以处理HTTP请求和响应的软件组件（从技术上来说，组件只是C＃类）。 ASP.NET Core应用程序中的每个中间件组件都执行以下任务。
从本篇开始将围绕asp.net core身份验证写个小系列，希望你看完本系列后，脑子里对asp.net core的身份验证原理有个大致印象。
当我们需要获取数据时，通常的做法是实例化依赖的类，然后调用类里面的方法，但是这种依赖方式会增加调用方和被调用方之间的耦合，也会增加应用程序维护成本及灵活性，同时增加了单元测试的难度
在2007年9月份，我曾经写了三篇详细介绍IIS架构和ASP.NET运行时管道的文章，深入介绍了IIS 5.x与IIS 6.0HTTP请求的监听与分发机制，以及ASP.NET运行时管道对HTTP请求的处理流程：
很多情况下目标Action方法都要求在一个安全上下文中被执行，这里所谓的安全上下文主要指的是当前请求者是一个经过授权的用户。授权的本质就是让用户在他许可的权限范围内做他能够做的事情，授权的前提是请求者是一个经过认证的用户。质询-应答（Chanllenge-Response）”是用户认证采用的一种常用的形式，认证方向被认证方发出质询以要求其提供用于实施认证的用户凭证，而被认证方提供相应的凭证以作为对质询的应答。旨在目标Action方法执行之前实施身分认证的AuthenticationFilter也对这种认证方
开篇：上一篇我们了解了一个ASP.Net页面请求的核心处理入口，它经历了三个重要的入口，分别是：ISAPIRuntime.ProcessRequest()、HttpRuntime.ProcessRequest()以及HttpApplication.Init()。其中，在HttpApplication的Init()方法中触发了请求处理管道事件的执行，本篇我们就来看看所谓的请求处理管道。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
