【ASP.NET Core】按用户等级授权

asp,net,core,用户,等级,授权 · 浏览次数 : 3229

小编点评

这段代码展示了如何根据用户等级生成授权策略,并在MVC控制器中通过 Policy 和 Authorize 属性实现此功能。 **主要代码如下:** - **LevelAuthorizationPolicyProvider**类:用于动态生成授权策略,根据用户等级返回相应的策略。 - **AuthorizationPolicyBuilder**类:用于构建授权策略。 - **Controller**类:用于定义控制器中的路由和授权配置。 **主要步骤:** 1. **配置策略:** - 创建一个名为 `LevelAuthorizationHandler` 的策略类,继承 `IAuthorizationPolicyProvider` 接口。 - 在 `GetPolicyAsync` 方法中,根据策略名称返回相应的策略。 2. **配置 MVC 中的授权:** - 在 `Configure` 方法中注册 `LevelAuthorizationHandler` 并注册 `LevelAuthorizationPolicyProvider`。 - 在路由中使用 `Authorize` 属性指定策略名称。 3. **访问不同的页面:** - 使用不同的策略名称访问不同的页面。 - 每个策略名称对应一个 `LevelAuthorizationRequirement`,该要求用户等级必须达到对应等级才能访问页面。 4. **动态授权:** - 使用 `LevelAuthorizationPolicyProvider` 中的 `GetPolicyAsync` 方法根据用户等级动态生成策略。 **示例:** 假设我们想为用户等级 3 和 5 创建授权策略,并将它们分别命名为 `Level3` 和 `Level5`。 ```csharp // LevelAuthorizationPolicyProvider public class LevelAuthorizationPolicyProvider : IAuthorizationPolicyProvider { private readonly AuthorizationOptions _options; public LevelAuthorizationPolicyProvider(IOptions<AuthorizationOptions> opt) { _options = opt.Value; } public Task<AuthorizationPolicy> GetDefaultPolicyAsync() { return Task.FromResult(_options.DefaultPolicy); } public Task<AuthorizationPolicy?> GetFallbackPolicyAsync() { return Task.FromResult(_options.FallbackPolicy); } public Task<AuthorizationPolicy?> GetPolicyAsync(string policyName) { if (policyName.StartsWith("Level3", StringComparison.OrdinalIgnoreCase) { // 动态生成策略 AuthorizationPolicyBuilder plcyBd = new AuthorizationPolicyBuilder(); plcyBd.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme); plcyBd.AddRequirements(new LevelAuthorizationRequirement(3)); return Task.FromResult(plcyBd.Build()); } else if (policyName.StartsWith("Level5", StringComparison.OrdinalIgnoreCase)) { // 动态生成策略 AuthorizationPolicyBuilder plcyBd = new AuthorizationPolicyBuilder(); plcyBd.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme); plcyBd.AddRequirements(new LevelAuthorizationRequirement(5)); return Task.FromResult(plcyBd.Build()); } // 未处理,交由选项类去返回默认的策略 return Task.FromResult(_options.GetPolicy(policyName)); } } ``` **注意:** * 此代码示例仅展示了如何生成策略并配置 MVC 中的授权。 * 对于不同的策略名称,您需要根据实际需求进行修改。

正文

验证和授权是两个独立但又存在联系的过程。验证是检查访问者的合法性,授权是校验访问者有没有权限查看资源。它们之间的联系——先验证再授权。

贯穿这两过程的是叫 Claim 的东东,可以叫它“声明”。没什么神秘的,就是由两个字符串组成的对象,一曰 type,一曰 value。type 和 value 有着映射关系,类似字典结构的 key 和 value。Claim 用来收集用户相关信息,比如

UserName = admin
Age = 105
Birth = 1990,4,12
Address = 火星街130号

ClaimTypes 静态类定义了一些标准的 type 值。如用户名 Name,国家 Country,手机号 MobilePhone,家庭电话 HomePhone 等等。你也可以自己定义一个,反正就是个字符串。

另外,还有一个 ClaimValueTypes 辅助类,也是一组字符串,用于描述 value 的类型。如 Integer、HexBinary、String、DnsName 等。其实所有 value 都是用字符串表示的,ValueTypes 只是基于内容本身的含义而定义的分类,在查找和分析 Claim 时有辅助作用。比如,值是 “00:15:30”,可以认为其 ValueType 是 Time,这样在分析这些数据时可以方便一些。

一般,代码会在 Sign in 前收集这些用户信息。作用是为后面的授权做准备。授权时会对这些用户信息进行综合评估,以决定该用户是否有能力访问某些资源。

回到本文主题。本文的重点是说授权,老周的想法是根据用户的等级来授权。比如,用户A的等级是2,如果某个URL要求4级以上的用户才能访问,那么A就无权访问了。

为了简单,老周就不建数据库这么复杂的东西了,直接写个类就好了。

public class User
{
    public string? UserName { get; set; }
    public string? Password { get; set; }

    /// <summary>
    /// 用户等级,1-5
    /// </summary>
    public int Level { get; set; } = 1;
}

上面类中,Level 属性表示的是用户等级。然后,用下面的代码来产生一些用户数据。

public static class UserDatas
{
    internal static readonly IEnumerable<User> UserList = new User[]
    {
        new(){UserName="admin", Password="123456", Level=5},
        new(){UserName="kitty", Password="112211", Level=3},
        new(){UserName="bob",Password="215215", Level=2},
        new(){UserName="billy", Password="886600", Level=1}
    };

    // 获取所有用户
    public static IEnumerable<User> GetUsers() => UserList;

    // 根据用户名和密码校对后返回的用户实体
    public static User? CheckUser(string username, string passwd)
    {
        return UserList.FirstOrDefault(u => u.UserName!.Equals(username, StringComparison.OrdinalIgnoreCase) && u.Password == passwd);
    }
}

这样的功能,对于咱们今天要说的内容,已经够用了。

关于验证,这里不是重点。所以老周用最简单的方案——Cookie。

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(opt =>
{
    opt.LoginPath = "/UserLog";
    opt.LogoutPath = "/Logout";
    opt.AccessDeniedPath = "/Denied";
    opt.Cookie.Name = "ck_auth_ent";
    opt.ReturnUrlParameter = "backUrl";
});

这个验证方案是结合 Session 和 Cookie 来完成的,也是Web身份验证的经典方案了。上述代码中我配置了一些选项:

LoginPath——当 SessionID 和 Cookie 验证不成功时,自动转到些路径,要求用户登录。

LogoutPath——退出登录(注销)时的路径。

AccessDeniedPath——访问被拒绝后转到的路径。

ReturnUrlParameter——回调URL,就是验证失败后会转到登录URL,然后会在URL参数中加一个回调URL。这个选项就是配置这个参数的名称的。比如这里我配置为backUrl。假如我要访问/home,但是,验证失败,跳转到 /UserLog 登录,这时候会在URL后面加上 /UserLog?backUrl=/home。如果登录成功且验证也成功了,就会跳转回 backUrl指定的路径(/home)。

这里要注意的是,我们不能把要求输入用户名和密码作为验证过程。验证由内置的 CookieAuthenticationHandler  类去处理,它只验证 Session 和 Cookie 中的数据是否匹配,而不是检查用户名/密码对不对。你想想,如果把检查用户名和密码作为验证过程,那岂不是每次都要让用户去输入一次?说不定每访问一个URL都要验证一次的,那用户不累死?所以,输入用户名/密码登录只在 LoginPath 选项中配置,只在必要时输入一次,然后配合 session 和 cookie 把状态记录下来,下次再访问,只验证此状态即可,不用再输入了。

LogoutPath 和 AccessDeniedPath 我就不弄太复杂了,直接这样就完事。

app.MapGet("/Denied", () => "访问被拒绝");
app.MapGet("/Logout", async (HttpContext context) =>
{
    await context.SignOutAsync();
});

对于 LoginPath,我用一个 Razor Pages 来处理。

@page
@using MyApp
@using Microsoft.AspNetCore.Authentication
@using Microsoft.AspNetCore.Authentication.Cookies
@using System.Security.Claims
@addTagHelper *,Microsoft.AspNetCore.Mvc.TagHelpers

<form method="post">
    <style>
        label{
            display:inline-block;
            min-width:100px;
        }
    </style>
    <div>
        <label for="userName">用户名:</label>
        <input type="text" name="userName" />
    </div>
    <div>
        <label for="passWord">密码:</label>
        <input type="password" name="passWord" />
    </div>
    <div>
        <button type="submit">登入</button>
    </div>
</form>

@functions{
    //[IgnoreAntiforgeryToken]
    public async void OnPost(string userName, string passWord)
    {
        var u = UserDatas.CheckUser(userName, passWord);
        if(u != null)
        {
            Claim[] cs = new Claim[]
            {
                new Claim(ClaimTypes.Name, u.UserName!),
                new Claim("level", u.Level.ToString())  //注意这里,收集重要情报
            };
            ClaimsIdentity id = new(cs, CookieAuthenticationDefaults.AuthenticationScheme);
            ClaimsPrincipal p = new(id);
            await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, p);
            //HttpContext.Response.Redirect("/");
        }
    }
}

其他的各位可以不关注,重点是 OnPost 方法,首先用刚才写的 UserDatas.CheckUser 静态方法来验证用户名和密码(这个是要我们自己写代码来完成的,CookieAuthenticationHandler 可不负责这个)。用户名和密码正确后,咱们就要收集信息了。收集啥呢?这个要根据你稍后在授权时要用到什么来决定的。就拿今天的主题来讲,我们需要知道用户等级,所以要收集 Level 属性的值。这里 ClaimType 我直接用“level”,Value 就是 Level 属性的值。

收集完用户信息后,要汇总到 ClaimsPrincipal 对象中,随后调用 HttpContext.SignInAsync 扩展方法,会触发 CookieAuthenticationHandler  去保存状态,因为它实现了 IAuthenticationSignInHandler 接口,从而带有 SignInAsync 方法。

   var ticket = new AuthenticationTicket(signInContext.Principal!, signInContext.Properties, signInContext.Scheme.Name);
    // 保存 Session
   if (Options.SessionStore != null)
   {
       if (_sessionKey != null)
       {
           // Renew the ticket in cases of multiple requests see: https://github.com/dotnet/aspnetcore/issues/22135
           await Options.SessionStore.RenewAsync(_sessionKey, ticket, Context, Context.RequestAborted);
       }
       else
       {
           _sessionKey = await Options.SessionStore.StoreAsync(ticket, Context, Context.RequestAborted);
       }

       var principal = new ClaimsPrincipal(
           new ClaimsIdentity(
               new[] { new Claim(SessionIdClaim, _sessionKey, ClaimValueTypes.String, Options.ClaimsIssuer) },
               Options.ClaimsIssuer));
       ticket = new AuthenticationTicket(principal, null, Scheme.Name);
   }
  // 生成加密后的 Cookie 值
   var cookieValue = Options.TicketDataFormat.Protect(ticket, GetTlsTokenBinding());

    // 追加 Cookie 到响应消息中
   Options.CookieManager.AppendResponseCookie(
       Context,
       Options.Cookie.Name!,
       cookieValue,
       signInContext.CookieOptions);
 ……

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

好了,上面的都是周边工作,下面我们来干正事。

授权大体上分为两种模式:

1、基于角色授权。即“你是谁就给你相应的权限”。你是狼人吗?你是预言家吗?你是女巫吗?你是好人吗?是狼人就赋予你杀人的权限。

2、基于策略。老周觉得这个灵活性高一点(纯个人看法)。一个策略需要一定数量的约束条件,是否赋予用户权限就看他能否满足这些约束条件了。约束实现 IAuthorizationRequirement 接口。这个接口未包含任何成员,因此你可以自由发挥了。

这只不过是按用途来划分的,从类型本质上看,就是一堆 IAuthorizationRequirement  组合起来提供给了 AuthorizationHandlerContext,AuthorizationHandlerContext 再通过一堆 IAuthorizationHandler 来处理。最后由 IAuthorizationEvaluator 去总结授权的结果

这里咱们需要的约束条件是用户等级,所以,咱们实现一个 LevelAuthorizationRequirement。

 public class LevelAuthorizationRequirement : IAuthorizationRequirement
 {
     public int Level { get; private set; }

     public LevelAuthorizationRequirement(int lv)
     {
         Level = lv;
     }
 }

授权处理有两个接口:

1、IAuthorizationHandler:处理过程,一个授权请求可以执行多个 IAuthorizationHandler。一般用于授权过程中的某个阶段(或针对某个约束条件)。一个授权请求可以由多 IAuthorizationHandler 参与处理。

2、IAuthorizationEvaluator:综合评估是否决定授权。评估一般在各种 IAuthorizationHandler 之后进行收尾工作。所以只执行一次就可以了,用于总结整个授权过程的情况得出最终结论(放权还是不放权)。

ASP.NET Core 内置了 DefaultAuthorizationEvaluator,这是默认实现,如无特殊需求,我们不会重新实现。

public class DefaultAuthorizationEvaluator : IAuthorizationEvaluator
{
    public AuthorizationResult Evaluate(AuthorizationHandlerContext context)
        => context.HasSucceeded
            ? AuthorizationResult.Success()
            : AuthorizationResult.Failed(context.HasFailed
                ? AuthorizationFailure.Failed(context.FailureReasons)
                : AuthorizationFailure.Failed(context.PendingRequirements));
}

所以,咱们的代码可以选择实现一个抽象类:AuthorizationHandler<TRequirement>,其中,TRequirement 需要实现 IAuthorizationRequirement 接口。这个抽象类已经满足咱们的需求了。

public class LevelAuthorizationHandler : AuthorizationHandler<LevelAuthorizationRequirement>
{
    // 策略名称,写成常量方便使用
    public const string POLICY_NAME = "Level";

    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, LevelAuthorizationRequirement requirement)
    {
        // 查找声明
        Claim? clm = context.User.Claims.FirstOrDefault(c => c.Type == "level");
        if(clm != null)
        {
            // 读出用户等级
            int lv = int.Parse(clm.Value);
            // 看看用户等级是否满足条件
            if(lv >= requirement.Level)
            {
                // 满足,标记此阶段允许授权
                context.Succeed(requirement);
            }
        }
        return Task.CompletedTask;
    }
}

在授权请求启动时,AuthorizationHandlerContext (上下文)对象会把所有 IAuthorizationRequirement 对象添加到一个哈希表中(HashSet<T>),表示一大串正等着授权处理的约束条件。

当我们调用 Succeed 方法时,会把已满足要求的 IAuthorizationRequirement  传递给方法参数。在 Success 方法内部会从哈希表中删除此 IAuthorizationRequirement,以表示该条件已满足了,不必再证。

public virtual void Succeed(IAuthorizationRequirement requirement)
{
    _succeedCalled = true;
    _pendingRequirements.Remove(requirement);
}

 

记得要在服务容器中注册,否则咱们写的 Handler 是不起作用的。

 builder.Services.AddSingleton<IAuthorizationHandler, LevelAuthorizationHandler>();

builder.Services.AddAuthorizationBuilder().AddPolicy(LevelAuthorizationHandler.POLICY_NAME, pb =>
{
    pb.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme);
    pb.AddRequirements(new LevelAuthorizationRequirement(3));
});

策略的名称我们前面以常量的方式定义了,记得否?

  public const string POLICY_NAME = "Level";

AddAuthenticationSchemes 是把此授权策略与一个验证方案关联,当进行鉴权时顺便做一次验证。上述代码我们关联 Cookie 验证即可,这个在文章前面已经设置了。AddRequirements 方法添加我们自定义的约束条件,这里我设置的用户等级是 3 —— 用户等级要 >= 3 才允许访问。

下面写个 MVC 控制器来检验一下是否能正确授权。

public class HomeController : Controller
{
    [HttpGet("/")]
    [Authorize(Policy = LevelAuthorizationHandler.POLICY_NAME)]
    public IActionResult Index()
    {
        return View();
    }
}

这里咱们用基于策略的授权方式,所以[Authorize]特性要指定策略名称。

好,运行。本来是访问根目录 / 的,但由于验证不通过,自动跳到登录页了。

 

 注意URL上的 backUrl 参数:?backUrl=/。本来要访问 / 的,所以登录后再跳回 / 。我们选一个用户等级为 5 的登录。

 

由于用户等级为 5,是 >=3 的存在,所以授权通过。

 

现在,把名为 ck_auth_ent 的Cookie删除。

 

 这个 ck_auth_ent 是在代码中配置的,还记得吗?

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(opt =>
{
    opt.LoginPath = "/UserLog";
    opt.LogoutPath = "/Logout";
    opt.AccessDeniedPath = "/Denied";
    opt.Cookie.Name = "ck_auth_ent";
    opt.ReturnUrlParameter = "backUrl";
});

现在咱们找个用户等级低于 3 的登录。

 

登录后被拒绝访问。

 

到此为止,好像、貌似、似乎已大功告成了。但是,老周又发现问题了:如果我一个控制器内或不同控制器之间有的操作方法要让用户等级 3 以上的用户访问,有些操作方法只要等级在 2 以上的用户就可以访问。这该咋整呢?有大伙伴可以会说了,那就多弄几个策略,每个策略代表一个等级。

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("Level3", pb =>
    {
        pb.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme);
        pb.AddRequirements(new LevelAuthorizationRequirement(3));
    })
    .AddPolicy("Level5", pb =>
    {
        pb.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme);
        pb.AddRequirements(new LevelAuthorizationRequirement(5));
    });

是的,这样确实是可行的。不过不够动态,要是我弄个策略从 Level1 到 Level10 呢,岂不要写十个?

官方有个用 Age 生成授权策略的示例让老周获得了灵感——是的,咱们就是要动态生成授权策略。需要用到一个接口:IAuthorizationPolicyProvider。这个接口可以根据策略名称返回授权策略,所以,咱们可以拿它做文章。

public class LevelAuthorizationPolicyProvider : IAuthorizationPolicyProvider
{
    private readonly AuthorizationOptions _options;

    public LevelAuthorizationPolicyProvider(IOptions<AuthorizationOptions> opt)
    {
        _options = opt.Value;
    }

    public Task<AuthorizationPolicy> GetDefaultPolicyAsync()
    {
        return Task.FromResult(_options.DefaultPolicy);
    }

    public Task<AuthorizationPolicy?> GetFallbackPolicyAsync()
    {
        return Task.FromResult(_options.FallbackPolicy);
    }

    public Task<AuthorizationPolicy?> GetPolicyAsync(string policyName)
    {
        if(policyName.StartsWith(LevelAuthorizationHandler.POLICY_NAME,StringComparison.OrdinalIgnoreCase))
        {
            // 比如,策略名 Level4,得到等级4
            // 提取名称最后的数字
            int prefixLen = LevelAuthorizationHandler.POLICY_NAME.Length;
            if(int.TryParse(policyName.Substring(prefixLen), out int level))
            {
                // 动态生成策略
                AuthorizationPolicyBuilder plcyBd = new AuthorizationPolicyBuilder();
                plcyBd.AddAuthenticationSchemes(CookieAuthenticationDefaults.AuthenticationScheme);
                plcyBd.AddRequirements(new LevelAuthorizationRequirement(level));
                // Build 方法生成策略
                return Task.FromResult(plcyBd.Build())!;
            }
        }
        // 未处理,交由选项类去返回默认的策略
        return Task.FromResult(_options.GetPolicy(policyName));
    }
}

这样可以根据给定的策略名称,生成与用户等级相关的配置。例如,名称“Level3”,就是等级3;“Level5”就是等级5。

于是,在配置服务容器时,我们不再需要 AddAuthorizationBuilder 一大段代码了,直接把 LevelAuthorizationPolicyProvider 注册一下就行了。

builder.Services.AddSingleton<IAuthorizationHandler, LevelAuthorizationHandler>();
builder.Services.AddTransient<IAuthorizationPolicyProvider, LevelAuthorizationPolicyProvider>();

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(opt =>
……

然后,在MVC控制器上咱们就可以666地玩了。

 public class HomeController : Controller
 {
     [HttpGet("/")]
     [Authorize(Policy = $"{LevelAuthorizationHandler.POLICY_NAME}3")]
     public IActionResult Index()
     {
         return View();
     }

     [HttpGet("/music")]
     [Authorize(Policy = $"{LevelAuthorizationHandler.POLICY_NAME}2")]
     public IActionResult Foo()
         => Content("2星级用户扰民音乐俱乐部");

     [HttpGet("/movie")]
     [Authorize(Policy = $"{LevelAuthorizationHandler.POLICY_NAME}5")]
     public IActionResult Movies()
         => Content("5星级鬼畜影院");
 }

这样一来,配置不同等级的授权就方便多了。

与【ASP.NET Core】按用户等级授权相似的内容:

【ASP.NET Core】按用户等级授权

验证和授权是两个独立但又存在联系的过程。验证是检查访问者的合法性,授权是校验访问者有没有权限查看资源。它们之间的联系——先验证再授权。 贯穿这两过程的是叫 Claim 的东东,可以叫它“声明”。没什么神秘的,就是由两个字符串组成的对象,一曰 type,一曰 value。type 和 value 有着

.NET周报【1月第2期 2023-01-13】

国内文章 【ASP.NET Core】按用户等级授权 https://www.cnblogs.com/tcjiaan/p/17024363.html 本文介绍了ASP.NET Core如何按照用户等级进行授权。 在 C# 9 中使用 foreach 扩展 https://www.cnblogs.co

【ASP.NET Core】按用户角色授权

上次老周和大伙伴们分享了有关按用户Level授权的技巧,本文咱们聊聊以用户角色来授权的事。 按用户角色授权其实更好弄,毕竟这个功能是内部集成的,多数场景下我们不需要扩展,不用自己写处理代码。从功能语义上说,授权分为按角色授权和按策略授权,而从代码本质上说,角色权授其实是包含在策略授权内的。怎么说呢?

ASP.NET Core中创建中间件的几种方式

前言 今天我们一起来盘点一下在ASP.NET Core应用程序中添加和创建中间件常见的四种方式。 中间件介绍 ASP.NET Core中间件(Middleware)是用于处理HTTP请求和响应的组件,它们被安排在请求处理管道中,并按顺序执行。中间件的设计是为了使其在请求处理管道中能够以灵活和可扩展的

推荐十个优秀的ASP.NET Core第三方中间件,你用过几个?

ASP.NET Core 作为一个强大的、跨平台的、高性能的开源框架,为开发者提供了丰富的功能和灵活的扩展性。其中,中间件(Middleware)是 ASP.NET Core 架构中的核心组件之一,它负责处理 HTTP 请求和响应的管道,允许开发者在请求和响应之间插入自定义逻辑。随着 ASP.NET

Asp-Net-Core开发笔记:使用原生的接口限流功能

前言 之前介绍过使用 AspNetCoreRateLimit 组件来实现接口限流 从 .Net7 开始,AspNetCore 开始内置限流组件,当时我们的项目还在 .Net6 所以只能用第三方的 现在都升级到 .Net8 了,当然是得来试试这个原生组件 体验后:配置使用都比较简单,不过功能也没有 A

ASP.NET Core如何禁用模型验证(或者从模型状态中移除某些属性)?

这是一篇4年前的文章:【经验分享】在ASP.NET Core中,如果禁用某个请求的模型验证? 事隔多年,又有网友问到这个问题。我就来重新整理一下,顺便扩展一下之前的解决办法。 这是一个来自网友【David】的提问。在 AppBoxCore 项目的新增用户页面,新增一个上传按钮:

Asp-Net-Core开发笔记:进一步实现非侵入性审计日志功能

前言 上次说了利用 AOP 思想实现了审计日志功能,不过有同学反馈还是无法实现完全无侵入,于是我又重构了一版新的。 回顾一下:Asp-Net-Core开发笔记:实现动态审计日志功能 现在已经可以实现对业务代码完全无侵入的审计日志了,在需要审计的接口上加上 [AuditLog] 特性,就可以记录这个接

Asp .Net Core 系列:国际化多语言配置

目录概述术语本地化器IStringLocalizer在服务类中使用本地化IStringLocalizerFactoryIHtmlLocalizerIViewLocalizer资源文件区域性回退配置 CultureProvider内置的 RequestCultureProvider实现自定义 Requ

安全机密管理:Asp.Net Core中的本地敏感数据保护技巧

前言 在我们开发过程中基本上不可或缺的用到一些敏感机密数据,比如SQL服务器的连接串或者是OAuth2的Secret等,这些敏感数据在代码中是不太安全的,我们不应该在源代码中存储密码和其他的敏感数据,一种推荐的方式是通过Asp.Net Core的机密管理器。 机密管理器 在 ASP.NET Core