.NET Core API条件身份验证属性，用于开发和生产 [英] .NET Core API Conditional Authentication attributes for Development & Production

问题描述

长话短说，是否可以在我的API上放置一个基于环境的授权属性，以便在开发中关闭授权限制，然后在生产中重新打开授权限制?

Long story short, Is it possible to place an environment based authorization attribute on my API so that the authorization restriction would be turned off in development and turned back on in Production?

我有一个单独的Angular 2项目，希望与之一起调用.NET Core API.我们创建了一个单独的项目，因此我们可以在vscode中打开Angular 2项目并调试打字稿.完成后，出于安全原因，我们将构建项目并将其放置在.NET Core项目中.

I have a separate Angular 2 project that I wish to call a .NET Core API with. We created a separate project so we could open the Angular 2 project in vscode and debug the typescript. When we are finished, we will build the project and place it inside the .NET Core project for security reasons.

我们的问题是，在调试阶段，我们无法连接到API，因为它们是两个单独的项目，而我们的Angular 2项目没有Active Directory. .NET Core项目当前具有身份验证属性，并且不允许访问(401)API.如果我们可以在开发过程中将其关闭然后在生产过程中重新打开，那就太好了.

Our problem is that during the debugging stages, we are unable to connect to the API because they are two separate projects and our Angular 2 project does not have Active Directory. The .NET Core project currently has Authentication Attributes and wont allow access (401) to the API. It would be nice if we could turn that off during development and back on during production.

我也愿意就如何最好地解决此问题提出其他建议.

I'm also open to any other suggestions on how we can best solve this problem.

[Authorize: (Only in Production)] <-- // something like this???
[Route("api/[controller]")]
public class TestController : Controller
{
    ...

推荐答案

ASP.NET Core授权基于策略.如您所见，AuthorizeAttribute可以采用策略名称，因此它知道要满足授权请求需要满足哪些条件.我建议您阅读优质文档关于这个问题.

ASP.NET Core authorization is based on policies. As you may have seen, the AuthorizeAttribute can take a policy name so it knows which criteria need to be satisfied for the request to be authorized. I suggest that you have a read of the great documentation on that subject.

回到您的问题，看来您没有使用特定的策略，因此它使用了默认策略，即

Back to your problem, it looks like you don't use a specific policy, so it uses the default one, which requires the user to be authenticated by default.

您可以在Startup.cs中更改该行为.如果您处于开发模式，则可以重新定义默认策略，以使其没有任何要求:

You can change that behaviour in Startup.cs. If you're in development mode, you can redefine the default policy so that it doesn't have any requirements:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(x =>
    {
        // _env is of type IHostingEnvironment, which you can inject in
        // the ctor of Startup
        if (_env.IsDevelopment())
        {
            x.DefaultPolicy = new AuthorizationPolicyBuilder().Build();
        }
    });
}

---

更新

im1dermike在评论中提到AuthorizationPolicy至少需要一个要求，因为我们可以看到

---

Update

im1dermike mentioned in a comment that an AuthorizationPolicy needs at least one requirement, as we can see here. That code wasn't introduced recently, so it means the solution above was broken the whole time.

要解决此问题，我们仍然可以利用AuthorizationPolicyBuilder的"noreferrer> RequireAssertion 方法并添加一个虚拟需求.看起来像这样:

To work around this, we can still leverage the RequireAssertion method of AuthorizationPolicyBuilder and add a dummy requirement. This would look like:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthorization(x =>
    {
        // _env is of type IHostingEnvironment, which you can inject in
        // the ctor of Startup
        if (_env.IsDevelopment())
        {
            x.DefaultPolicy = new AuthorizationPolicyBuilder()
                .RequireAssertion(_ => true)
                .Build();
        }
    });
}

这确保了我们在授权策略中至少有一项要求，并且我们知道它将始终通过.

This ensures we have at least one requirement in the authorization policy, and we know that it will always pass.

这篇关于.NET Core API条件身份验证属性，用于开发和生产的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！