ASP.NET Core

ASP.NET CORE3.0 API Swagger+IdentityServer4授权验证

冷暖自知 提交于 2020-08-12 02:25:34
一、配置IdentityServer4服务端 这里介绍两种方法 ①直接创建identityserver4的模板,在模板的基础上修改 ②创建新项目,自己搭建 第一种 参考 我的 identityServer4学习 ,创建一个identityServer4模板后 修改config文件 public static IEnumerable<IdentityResource> GetIdentityResources() { return new IdentityResource[] { new IdentityResources.OpenId(), new IdentityResources.Profile(), }; } /// <summary> /// API信息 /// </summary> /// <returns></returns> public static IEnumerable<ApiResource> GetApis() { return new [] { new ApiResource( " ProjectApiScope " , " Demo API with Swagger " ) }; } /// <summary> /// 客服端信息 /// </summary> /// <returns></returns> public static

Asp.NET Core Nginx Ocelot ForwardedHeaders X-Forwarded-For

安稳与你 提交于 2020-08-12 01:18:49
原文: Asp.NET Core Nginx Ocelot ForwardedHeaders X-Forwarded-For ocelot在部署时我使用了nginx作为转发,并配置了https证书,但是发现ocelot不支持Forward host header。 https://ocelot.readthedocs.io/en/latest/introduction/notsupported.html 这时候我就有了个疑问,Forward host header到底时什么含义?于是便有了本文。 nginx等代理服务器在转发时,会使用X-Forwarded-For 请求头。该请求头会记录从请求者ip到层层代理服务器ip的信息。 https://imququ.com/post/x-forwarded-for-header-in-http.html https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For asp.net core 在使用转发服务器后,官方文档说需要使用中间件设置XForwardedFor与XForwardedProto https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view

ASP.NET Core中处理中止的请求

丶灬走出姿态 提交于 2020-08-11 21:28:26
当用户向应用程序发出请求时,服务器将解析该请求,生成响应,然后将结果发送给客户端。用户可能会在服务器处理请求的时候中止请求。就比如说用户跳转到另一个页面中获取说关闭页面。在这种情况下,我们希望停止所有正在进行的工作,以浪费不必要的资源。例如我们可能要取消SQL请求、http调用请求、CPU密集型操作等。 ASP.NET Core提供了HTTPContext.RequestAborted检测客户端何时断开连接的属性,我们可以通过 IsCancellationRequested 以了解客户端是否中止连接。 [ApiController] [Route("[controller]")] public class WeatherForecastController : ControllerBase { [HttpGet] public async Task<WeatherForecast> Get() { CancellationToken cancellationToken = HttpContext.RequestAborted; if (cancellationToken.IsCancellationRequested) { //TODO aborted request } return await GetWeatherForecasts(cancellationToken); }

[ASP.NET Core 3框架揭秘] 依赖注入[8]:服务实例的生命周期

我的梦境 提交于 2020-08-11 20:53:45
生命周期决定了IServiceProvider对象采用怎样的方式提供和释放服务实例。虽然不同版本的依赖注入框架针对服务实例的生命周期管理采用了不同的实现,但总的来说原理还是类似的。在我们提供的 依赖注入框架Cat 中,我们已经模拟了三种生命周期模式的实现原理,接下来我们结合“服务范围”的概念来对这个话题做进一步讲述。 一、服务范围(Service Scope) 对于依赖注入框架采用的三种生命周期模式(Singleton、Scoped和Transient)来说,Singleton和Transient都具有明确的语义,但是Scoped代表一种怎样的生命周期模式,很多初学者往往搞不清楚。这里所谓的Scope指的是由IServiceScope接口表示的“服务范围”,该范围由IServiceScopeFactory接口表示的“服务范围工厂”来创建。如下面的代码片段所示,IServiceProvider的扩展方法CreateScope正是利用提供的IServiceScopeFactory服务实例来创建作为服务范围的IServiceScope对象。 public interface IServiceScope : IDisposable { IServiceProvider ServiceProvider { get ; } } public interface

(三)学习了解OrchardCore笔记——灵魂中间件ModularTenantContainerMiddleware的第一行①的模块部分

醉酒当歌 提交于 2020-08-11 20:49:55
  了解到了OrchardCore主要由两个中间件(ModularTenantContainerMiddleware和ModularTenantRouterMiddleware)构成,下面开始了解ModularTenantContainerMiddleware中间件第一行代码。   了解asp.net core机制的都知道中间件是由构造函数和Invoke(或者InokeAsync)方法构成,构造函数不过就是个依赖注入的过程,Invoke也可以直接依赖注入,两者的区别是构造函数时全局的,Invoke只是当次请求,所以从Inovke开始了解! public async Task Invoke(HttpContext httpContext) { // Ensure all ShellContext are loaded and available. await _shellHost.InitializeAsync(); var shellSettings = _runningShellTable.Match(httpContext); // We only serve the next request if the tenant has been resolved. if (shellSettings != null ) { if (shellSettings.State ==

ASP.NET Core 2.2 : 二十七. JWT与用户授权(细化到Action)

青春壹個敷衍的年華 提交于 2020-08-11 18:20:40
上一章分享了如何在ASP.NET Core中应用JWT进行用户认证以及Token的刷新,本章继续进行下一步,用户授权。涉及到的例子也以 上一章 的为基础。( ASP.NET Core 系列目录 ) 一、概述   首先说一下认证(authentication)与授权(authorization),它们经常在一起工作,所以有时候会分不清楚。并且这两个英文单词长得也像兄弟。举例来说,我刷门禁卡进入公司,门禁【认证】了我是这里的员工,可以进入;但进入公司以后,我并不是所有房间都可以进,比如“机房重地,闲人免进”,我能进入哪些房间,需要公司的【授权】。这就是认证和授权的区别。   ASP.NET Core提倡的是基于声明( Claim )的授权,关于这个Claim,上一章用到过,有如下这样的代码,但没有介绍: Claim[] claims = new Claim[] { new Claim(ClaimTypes.NameIdentifier, user.Code), new Claim(ClaimTypes.Name, user.Name) }; 这是一个声明的集合,它包含了两个 声明,用于保存了用户的唯一ID和用户名。当然我们还可以添加更多的Claim。对应Claim,还有ClaimsIdentity 和ClaimsPrincipal 两个类型。

使用命名管道承载gRPC

那年仲夏 提交于 2020-08-11 17:36:51
最近GRPC很火,感觉整RPC不用GRPC都快跟不上时髦了。 gRPC设计 gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统,自然而然就盯上了它,但是它真能够解决所有问题吗?不见得,先看看他的优点: gRPC的主要优点: 现代高性能轻量级 RPC 框架。 协定优先 API 开发,默认使用协议缓冲区,允许与语言无关的实现。 可用于多种语言的工具,以生成强类型服务器和客户端。 支持客户端、服务器和双向流式处理调用。 使用 Protobuf 二进制序列化减少对网络的使用。 对应的适用场景: 微服务 :gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。 点对点实时通信 :gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。 多语言环境 :gRPC 工具支持所有常用的开发语言,因此,gRPC 是多语言环境的理想选择。 网络受限环境 :gRPC 消息使用 Protobuf(一种轻量级消息格式)进行序列化。 gRPC 消息始终小于等效的 JSON 消息。 gRPC还是有缺点的: 浏览器支持受限 :绝大数浏览器不支持 HTTP/2 非人工可读取 :proto文件规定的格式在通讯中会序列化成二进制数据,人工解析较为困难。 不适用的场景与替代: 浏览器可访问的API :gRPC

ASP.NET Core Authentication and Authorization

喜夏-厌秋 提交于 2020-08-11 16:20:43
原文: ASP.NET Core Authentication and Authorization 最近把一个Asp .net core 2.0的项目迁移到Asp .net core 3.1,项目启动的时候直接报错: InvalidOperationException : Endpoint CoreAuthorization .Controllers .HomeController .Index ( CoreAuthorization ) contains authorization metadata , but a middleware was not found that supports authorization . Configure your application startup by adding app .UseAuthorization () inside the call to Configure (..) in the application startup code . The call to app .UseAuthorization () must appear between app .UseRouting () and app .UseEndpoints (...). Microsoft .AspNetCore .Routing

asp.net core 3.1 cookie httpOnly 登录验证

梦想与她 提交于 2020-08-11 13:52:12
原文: asp.net core 3.1 cookie httpOnly 登录验证 region set-cookie to ie 1.startup.cs ConfigureServices 添加 //注册Cookie认证服务 services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, option => { option.AccessDeniedPath = "/Login"; //当用户尝试访问资源但没有通过任何授权策略时,这是请求会重定向的相对路径资源 option.LoginPath = "/Login/"; option.Cookie.Name = "token";//设置存储用户登录信息(用户Token信息)的Cookie名称 option.Cookie.HttpOnly = true;//设置存储用户登录信息(用户Token信息)的Cookie,无法通过客户端浏览器脚本(如JavaScript等)访问到 //option.Cookie.SecurePolicy = Microsoft.AspNetCore.Http

介绍一个基于 .NET 的船新 PHP SDK + Runtime: PeachPie

自古美人都是妖i 提交于 2020-08-11 13:42:17
前言 这几天想基于 .NET Core 搞一个自己的博客网站,于是在网上搜刮各种博客引擎,找到了这些候选:Blogifier、Miniblog 以及 edi 写的 Moonglate。 Blogifier:这是前端是个 Angular SPA 应用,不利于 SEO,同时首屏加载速度慢,因此排除。 Miniblog:顾名思义 Mini,可以完美承载内容但是主题实在是过于简单,没有可自定义性,因此排除。 Moonglate:总体感觉不错,界面设计得也很好,功能全面,然而需要 SQL Server 作为数据库,然而 SQL Server 虽然有 Linux 版本,但受限于主机配置和预算因此也被排除。 难道就没有适合我需求的博客引擎了吗?答案当然是:有。 众所周知 PHP 是世界上最好的语言(滑稽),还是众所周知有一个叫做 WordPress 的博客引擎生态非常庞大,而且是使用 PHP 构建的。 可是 PHP 和 .NET 又有什么关系呢? PeachPie PeachPie 是一个完全构建于 .NET Standard 之上的一套完整的 PHP SDK + Runtime,包含编译器和运行时等等,兼容 PHP 5.4-7.4(当然部分功能仍在开发中)。 官网: https://www.peachpie.io 那么 PeachPie 有什么优点呢: 开源: https://github