1.跟我一起学.NetCore之中间件(Middleware)简介和解析请求管道构建
2.使用.NET Core和Vue搭建WebSocket聊天室
3.ASP.NET Core MVC中的中e中两种404错误
4..netcorewebapi如何处理接口统一返回值错误信息?
5.ASP.NET Core认证原理和实现
6.AspNetCore打造一个“最安全”的api接口

跟我一起学.NetCore之中间件(Middleware)简介和解析请求管道构建

       前言

       中间件(Middleware)对于Asp.NetCore项目来说，不能说重要，间件间件而是源码原理不能缺少，因为Asp.NetCore的中e中请求管道就是通过一系列的中间件组成的；在服务器接收到请求之后，请求会经过请求管道进行相关的间件间件过滤或处理；

       正文

       那中间件是那路大神？

       会经常听说，需要注册一下中间件，源码原理tinydnn源码如图：

       所以说，中e中中间件是间件间件针对请求进行某种功能需求封装的组件，而这个组件可以控制是源码原理否继续执行下一个中间件；如上图中的app.UserStaticFiles()就是注册静态文件处理的中间件，在请求管道中就会处理对应的中e中请求，如果没有静态文件中间件，间件间件那就处理不了静态文件(如html、源码原理css等)；这也是中e中Asp.NetCore与 Asp.Net不一样的地方，前者是间件间件根据需求添加对应的中间件，而后者是源码原理提前就全部准备好了，不管用不用，反正都要路过，这也是Asp.NetCore性能比较好的原因之一；

       而对于中间件执行逻辑，官方有一个经典的图：

       如图所示，请求管道由一个个中间件(Middleware)组成，每个中间件可以在请求和响应中进行相关的逻辑处理，在有需要的情况下，当前的中间件可以不传递到下一个中间件，从而实现断路；如果这个不太好理解，如下图：

       每层外圈代表一个中间件，黑圈代表最终的Action方法，当请求过来时，会依次经过中间件，Action处理完成后，返回响应时也依次经过对应的中间件，而执行的顺序如箭头所示；(这里省去了一些其他逻辑，只说中间件)。网站导航精品源码

       好了好了，理论说不好，担心把看到的小伙伴绕进去了，就先到这吧，接下来从代码中看看中间件及请求管道是如何实现的；老规矩，找不到下手的地方，就先找能"摸"的到的地方，这里就先扒静态文件的中间件：

       UseMiddleware方法实现

       以上代码其实现在拿出来有点早了，以上是对自定义中间件的注册方式，为了扒代码的逻辑完整，拿出来了；这里可以不用深究里面内容，知道内部调用了IApplicationBuilder的Use方法即可；

       由此可见，IApplicationBuilder就是构造请求管道的核心类型，如下：

       IApplicationBuilder的默认实现就是ApplicationBuilder，走起，一探究竟：

       在注册的代码中，可以看到所谓的中间件就是Func，其中RequestDelegate就是一个委托，用于处理请求的，如下：

       之所以用Func的形式表示中间件，应该就是为了中间件间驱动方便，毕竟中间件不是单独存在的，是需要多个中间件结合使用的；

       那请求管道构造完成了，那请求是如何到管道中呢？

       应该都知道，Asp.NetCore内置了IServer(如Kestrel)，负责监听对应的请求，当请求过来时，会将请求给IHttpApplication进行处理，简单看一下接口定义：

       而对于IHttpApplication类型来说，默认创建的就是HostingApplication，如下：

       这里关于Server监听到请求及将请求交给中间处理的开盘抓涨停源码具体过程没有具体描述，可以结合启动流程和以上内容在细扒一下流程吧(大家私下搞吧)，这里就简单说说中间件及请求管道构建的过程；(后续有时间将整体流程走一遍)；

       总结

       这节又是纯代码来“忽悠”小伙伴了，对于理论概念可能表达的不够清楚，欢迎交流沟通；其实这里只是根据流程走了一遍源码，并没有一行行解读，所以小伙伴看此篇文章代码部分的时候，以调试的思路去看，从注册中间件那块开始，到最后请求交给请求管道处理，注重这个流程即可；

       下一节说说中间件的具体应用；

       ------------------------------------------------

       一个被程序搞丑的帅小伙，关注"Code综艺圈"，识别关注跟我一起学~~~

使用.NET Core和Vue搭建WebSocket聊天室

       使用.NET Core和Vue搭建WebSocket聊天室，本文将深入讲解WebSocket协议及其优势，以及如何基于WebSocket构建实时应用。WebSocket是一种在HTML5标准中引入的网络通信协议，解决了HTTP协议的“请求-响应”模型带来的限制，使其能够实现客户端和服务器之间的双向通信，无需频繁的轮询操作。WebSocket的引入使得实时业务场景如在线聊天室、实时监控等得以实现。

       WebSocket协议的兼容性与效率得到了保证，因为它基于HTTP协议，同时具备对HTTP协议的良好兼容性。其无同源限制的特点，允许客户端与任意服务器进行通信，通过单一连接支持上下游通信的能力。与HTTP协议相比，WebSocket在握手阶段使用了HTTP协议，但在建立连接后，实现了双向通信，有效提高了实时应用的安卓书店源码效率和响应速度。

       以一个简单的网络聊天室为例，本文将展示如何结合.NET Core和Vue构建WebSocket聊天室。在服务端，采用.NET Core实现WebSocket功能，而客户端则采用Vue的双向绑定特性。本例中，客户端和服务端的实现紧密协作，确保了实时消息的传递。具体实现步骤包括安装.NET Core库，配置中间件，以及处理客户端的WebSocket请求。

       在服务端实现中，我们首先需要安装Microsoft.AspNetCore.WebSockets库，并在Startup类的Configure方法中添加WebSocket中间件。配置WebSocket中间件时，可以设置KeepAliveInterval和ReceiveBufferSize，以优化连接的稳定性和性能。通过检查请求地址和判断是否为WebSocket请求，可以实现客户端与服务器的握手，并开始消息的接收与发送。

       在客户端实现中，我们采用原生WebSocket API与Vue框架进行交互，实现消息的发送与接收。通过监听回调函数，如onopen、onmessage、onerror和onclose，可以实现实时消息的实时更新。Vue的双向绑定特性简化了界面与后端数据的同步，使得聊天室功能更加流畅。

       为了进一步提升实时应用的mbr锁机源码体验，本文介绍了如何将WebSocket聊天室功能封装为中间件。这样可以将不同WebSocket实例隔离开，同时减轻Startup类的负担。通过中间件，我们可以为不同的聊天室实例提供独立的会话管理，确保消息的正确分发。

       本文通过WebSocket聊天室案例，展示了如何结合.NET Core和Vue构建实时应用。在服务端，通过配置中间件实现WebSocket功能；客户端则利用原生WebSocket API与Vue框架实现界面的实时更新。通过中间件的使用，提高了代码的复用性和可维护性。本例不仅适用于实时聊天室应用，也适用于其他需要实时数据推送的场景。未来，我们将继续探索服务器端的数据推送技术，而客户端将作为数据展现层发挥关键作用。希望本文能够为构建实时应用提供有价值的参考。

ASP.NET Core MVC中的两种错误

       我们在使用某些系统的时候，如果访问了一个不存在的地址怎么办，比如 abp.com/airport/fly；或者访问的地址路由和操作方法虽然存在，但是地址参数id不存在，比如 abp.com/BlogDetails/5这个信息是存在的，但是更改访问 abp.com/BlogDetails/1...时，则提示博客内容不存在。

       在我们的系统中要如何处理呢？本章主要向读者介绍如下内容。在HTTP状态码中，4××和5××分别代表请求错误和服务器在处理请求中的错误或异常状态。

       4××系列表示请求错误，代表了客户端可能发生了错误，从而妨碍了服务器的处理。常见的有状态码、状态码和状态码。5××系列表示服务器在处理请求的过程中有错误或者异常状态发生，也可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见的有状态码和状态码。

       错误信息有两种，我们在之前已经提及了。首先了解第一种：找不到指定ID的信息。当无法通过指定的ID找到学生、产品和客户等信息的时候产生错误，可以参考HomeController中的Details()的方法，代码如下。

       可以通过传递一个ID为的值来调用HomeController中的Details()方法: corewebapi如何处理接口统一返回值错误信息?

       在.NET Core Web API开发中，统一处理接口返回值错误信息是至关重要的步骤。接口作为后端与客户端（如Web前端或App）交互的桥梁，其数据返回格式应当遵循统一规范，以便客户端开发者能够更高效地处理接收到的数据。

       通常，合格的接口返回值应该包括状态码、提示信息和数据。例如：

       默认情况下，.NET Core Web API模板可能没有特定的返回格式，这要求开发者自定义并实现。在本文中，通过创建自定义的返回值类，如`ApiResponse`及其派生类型，实现了一种统一的返回格式。这种方法已经在多个项目中应用，实际上已经演变为一种具有实用价值的组件。

       此外，将返回值发布为NuGet包，方便在其他项目中复用，避免了重复编写代码，提高了开发效率。

       在开发中，.NET Core Web API控制器通常需要继承`ControllerBase`类。接口`Action`的返回值可以通过`IActionResult`或`ActionResult`类型来定义，并结合`Ok()`、`NotFound()`等方法自动设置HTTP状态码。然而，为了让API在Swagger文档中直观展示数据类型，通常会采用特定的返回类型，如`ApiResponse`。

       当需要返回`ApiResponse`时，只返回状态码可能会导致问题，因为这意味着所有接口的响应都无错误。为了解决这个问题，可以采用多种策略，包括使用中间件或过滤器来统一处理返回值。

       中间件和过滤器是.NET Core管道模型的重要组成部分，可以用来修改请求或响应的流程。例如，在`Program.cs`中配置管道时，可以添加处理`MVC`的`Endpoint`，并利用过滤器来实现接口返回值的统一包装。

       具体实现中，定义了`ApiResponse`类，包括基本的响应数据和状态码、提示信息。通过运算符重载实现类型隐式转换，使得代码编写更加简洁。在处理非`ApiResponse`类型的数据时，使用过滤器来检查响应结果是否为`ObjectResult`，如果符合，则包装成`ApiResponse`格式。

       通过上述方法，所有接口的返回格式被统一为具有状态码、提示信息和数据的`ApiResponse`类。这种统一的返回格式使得接口更加规范，易于理解和维护。

       最后，将`ApiResponse`类封装成NuGet包，便于在其他项目中引用，减少了代码重复和维护工作。同时，注意过滤器功能不包含在包中，以便根据项目需求灵活定制。

ASP.NET Core认证原理和实现

       é€šå¸¸åœ¨åº”用程序中，安全分为前后两个步骤：验证和授权。验证负责检查当前请求者的身份，而授权则根据上一步得到的身份决定当前请求者是否能够访问期望的资源。

        既然安全从验证开始，我们也就从验证开始介绍安全。

        我们先从比较简单的场景开始考虑，例如在 Web API 开发中，需要验证请求方是否提供了安全令牌，安全令牌是否有效。如果无效，那么 API 端应该拒绝提供服务。在命名空间 Microsoft.AspNetCore.Authentication 下，定义关于验证的核心接口。对应的程序集是 Microsoft.AspNetCore.Authentication.Abstractions.dll。

        在 ASP.NET 下，验证中包含 3 个基本操作：

        验证操作负责基于当前请求的上下文，使用来自请求中的信息，例如请求头、Cookie 等等来构造用户标识。构建的结果是一个 AuthenticateResult 对象，它指示了验证是否成功，如果成功的话，用户标识将可以在验证票据中找到。

        常见的验证包括：

        在授权管理阶段，如果用户没有得到验证，但所期望访问的资源要求必须得到验证的时候，授权服务会发出质询。例如，当匿名用户访问受限资源的时候，或者当用户点击登录链接的时候。授权服务会通过质询来相应用户。

        例如

        质询操作应该让用户知道应该使用何种验证机制来访问请求的资源。

        在授权管理阶段，如果用户已经通过了验证，但是对于其访问的资源并没有得到许可，此时会使用拒绝操作。

        例如：

        拒绝访问处理应该让用户知道：

        在这个场景下，可以看到，验证需要提供的基本功能就包括了验证和验证失败后的拒绝服务两个操作。在 ASP.NET Core 中，验证被称为 Authenticate，拒绝被称为 Forbid。 在供消费者访问的网站上，如果我们希望在验证失败后，不是像 API 一样直接返回一个错误页面，而是将用户导航到登录页面，那么，就还需要增加一个操作，这个操作的本质是希望用户再次提供安全凭据，在 ASP.NET Core 中，这个操作被称为 Challenge。这 3 个操作结合在一起，就是验证最基本的要求，以接口形式表示，就是 IAuthenticationHandler 接口，如下所示：

        验证的结果是一个 AuthenticateResult 对象。值得注意的是，它还提供了一个静态方法 NoResult() 用来返回没有得到结果，静态方法 Fail() 生成一个表示验证异常的结果，而 Success() 成功则需要提供验证票据。

        通过验证之后，会返回一个包含了请求者票据的验证结果。

        在 GitHub 中查看 AuthenticateResult 源码

        那么验证的信息来自哪里呢？除了前面介绍的 3 个操作之外，还要求一个初始化的操作 Initialize，通过这个方法来提供当前请求的上下文信息。

        在 GitHub 中查看 IAuthenticationHandler 定义

        有的时候，我们还希望提供登出操作，增加登出操作的接口被称为 IAuthenticationSignOutHandler。

        在 GitHub 中查看 IAuthenticationSignOutHandler 源码

        在登出的基础上，如果还希望提供登录操作，那么就是 IAuthenticationSignInHandler 接口。

        在 GitHub 中查看 IAuthenticationSignInHandler 源码

        直接实现接口还是比较麻烦的，在命名空间 Microsoft.AspNetCore.Authentication 下，微软提供了抽象基类 AuthenticationHandler 以方便验证控制器的开发，其它控制器可以从该控制器派生，以取得其提供的服务。

        通过类的定义可以看到，它使用了泛型。每个控制器应该有一个对应该控制器的配置选项，通过泛型来指定验证处理器所使用的配置类型，在构造函数中，可以看到它被用于获取对应的配置选项对象。

        在 GitHub 中查看 AuthenticationHandler 源码

        通过 InitializeAsync()，验证处理器可以获得当前请求的上下文对象 HttpContext。

        最终，作为抽象类的 ，希望派生类来完成这个验证任务，抽象方法 HandleAuthenticateAsync() 提供了扩展点。

        验证的结果是一个 AuthenticateResult。

        而拒绝服务则简单的多，直接在这个抽象基类中提供了默认实现。直接返回 HTTP 。

        剩下的一个也一样，提供了默认实现。直接返回 HTTP 响应。

        对于 JWT 来说，并不涉及到登入和登出，所以它需要从实现 IAuthenticationHandler 接口的抽象基类 AuthenticationHandler 派生出来即可。从 AuthenticationHandler 派生出来的 JwtBearerHandler 实现基于自己的配置选项 JwtBearerOptions。所以该类定义就变得如下所示，而构造函数显然配合了抽象基类的要求。

        在 GitHub 中查看 JwtBearerHandler 源码

        真正的验证则在 HandleAuthenticateAsync() 中实现。下面的代码是不是就很熟悉了，从请求头中获取附带的 JWT 访问令牌，然后验证该令牌的有效性，核心代码如下所示。

        在 GitHub 中查看 JwtBearerHandler 源码

        在 ASP.NET Core 中，你可以使用各种验证处理器，并不仅仅只能使用一个，验证控制器需要一个名称，它被看作该验证模式 Schema 的名称。Jwt 验证模式的默认名称就是 "Bearer"，通过字符串常量 JwtBearerDefaults.AuthenticationScheme 定义。

        在 GitHub 中查看 JwtBearerDefaults 源码

        最终通过 AuthenticationBuilder 的扩展方法 AddJwtBearer() 将 Jwt 验证控制器注册到依赖注入的容器中。

        在 GitHub 中查看 JwtBearerExtensions 扩展方法源码

        一种验证处理器，加上对应的验证配置选项，我们再为它起一个名字，组合起来就成为一种验证架构 Schema。在 ASP.NET Core 中，可以注册多种验证架构。例如，授权策略可以使用架构的名称来指定所使用的验证架构来使用特定的验证方式。在配置验证的时候，通常设置默认的验证架构。当没有指定验证架构的时候，就会使用默认架构进行处理。

        还可以

        注册的验证模式，最终变成 AuthenticationScheme，注册到依赖注入服务中。

        在 GitHub 中查看 AuthenticationScheme 源码

        各种验证架构被保存到一个 IAuthenticationSchemeProvider 中。

        在 GitHub 中查看 IAuthenticationSchemeProvider 源码

        最终的使用是通过 IAuthenticationHandlerProvider 来实现的，通过一个验证模式的字符串名称，可以取得所对应的验证控制器。

        在 GitHub 中查看 IAuthenticationHandlerProvider 源码

        它的默认实现是 AuthenticationHandlerProvider，源码并不复杂。

        在 GitHub 中查看 AuthenticationHandlerProvider 源码

        验证中间件的处理就没有那么复杂了。

        找到默认的验证模式，使用默认验证模式的名称取得对应的验证处理器，如果验证成功的话，把当前请求用户的主体放到当前请求上下文的 User 上。

        里面还有一段特别的代码，用来找出哪些验证处理器实现了 IAuthenticationHandlerProvider，并依次调用它们，看看是否需要提取终止请求处理过程。

        在 GitHub 中查看 AuthenticationMiddle 源码

AspNetCore打造一个“最安全”的api接口

       在构建安全的API接口时，选择正确的认证与授权策略是至关重要的。本文将引导你如何使用非对称加密（如RSA）结合ASP.NET Core框架，设计一个既安全又易于理解的API接口，确保数据在传输过程中不被篡改或窃取。本指南将分步骤详细介绍如何实现这一目标。

       首先，考虑性能影响，选择非对称加密方案，例如RSA 位公私钥对。这种加密方式在HTTP传输中分为请求与响应两个模式，确保数据在双向交互过程中安全性。非对称加密利用公钥和私钥对数据进行加密与解密，公钥用于加密数据，私钥用于解密数据，从而保证了数据的安全性与完整性。

       在实现这一加密过程时，公钥与私钥各有其作用。公钥用于验证消息来源，私钥用于生成独特的签名，以证明消息未被篡改。当系统A向系统B发送信息时，使用私钥对消息进行签名，系统B接收信息后使用公钥验证签名，确认信息来源及未被篡改。

       为了实现这一过程，首先创建一个ASP.NET Core Web API项目。在此基础上，设计并实现自定义认证授权体系，确保数据的传输安全。具体步骤包括创建配置选项、Scheme选项类、常量定义、认证处理器（AuthSecurityRsaAuthenticationHandler）、扩展方法、中间件（SafeResponseMiddleware）等。这些组件共同作用，形成一个完整的认证授权框架，确保API接口的访问符合预期的安全标准。

       在实现过程中，需要关注API接口的请求体解析与校验，通过IModelBinder实现模型绑定，确保数据的正确性。同时，采用特性解析（Attribute）对模型进行额外验证，确保数据输入符合业务逻辑。在Startup配置中整合这些组件，完成服务端API接口的构建。

       为客户端提供接口调用能力，实现RSA秘钥生成。通过下载并使用OpenSSL工具生成公钥与私钥，确保客户端能够与服务端进行安全交互。将生成的秘钥与API接口结合，实现双向加密与签名认证，进一步增强数据传输的安全性。

       在模型解析与校验的基础上，实现对响应结果的安全处理，确保数据在返回客户端时同样安全。通过编写客户端接口，与服务端进行交互测试，验证API接口的安全与稳定性。

       本指南提供的方法，不仅适用于构建安全的API接口，还适用于接入ASP.NET Core认证系统与权限管理，优化API接口的用户体验。虽然RSA加密在确保数据安全方面表现出色，但其性能可能会因数据大小增加而受到影响。实际应用中，可以根据需求选择对称加密（如AES或DES）进行数据加密，以提高性能。

       本文的目的是分享如何在使用ASP.NET Core框架时，设计与实现安全、高效的API接口，同时提供关于如何接入认证体系与模型校验的实践指导。希望本文能够帮助开发者构建出既安全又易于理解的API接口，为应用提供坚实的后端支持。