.NET Core Обходит или отключает [Авторизация(Роли="")] во время локальной разработки

Я думаю, вы можете использовать IClaimsTransformation за это. В этом случае я просто добавлю роль для всех, но когда она подключена, она будет работать только в том случае, если вы находитесь в разработке (примечание: вам нужно будет убедиться, что переменная среды установлена правильно, чтобы IsDevelopment работает).

AddRolesClaimsTransformation.cs

/// <summary>
/// Adds roles to a user on the fly, this will hard code a Buyer role for everyone.
/// </summary>
public class AddRolesClaimsTransformation : IClaimsTransformation
{
    public async Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
    {
        // Clone current identity
        var clone = principal.Clone();
        var ident = (ClaimsIdentity)clone.Identity;

        ident.AddClaim(new Claim(ClaimTypes.Role, "Buyer"));

        return clone;
    }
}

Startup.cs

// Only in dev
if (builder.Environment.IsDevelopment())
{
    builder.Services.AddScoped<IClaimsTransformation, AddRolesClaimsTransformation>();
}

Это должно сработать для ASP.NET Ядро 3.1 в соответствии с документами Microsoft. Однако я протестировал его против .NET 6 (в .NET 6 шаблоны для новых сайтов перемещают Startup.cs вещи в Program.cs).

Еще одно примечание, если вы полагаетесь на IsDevelopment сантехника, которая находится на WebHostEnvironment вам не придется использовать директивы компилятора. Таким образом, как только среда настроена, она будет работать, как бы вы ее там ни развертывали (например, нет шансов, что случайная отладочная сборка превратит ее в среду, в которой она не должна быть).

Вместо того, чтобы явно указывать роли, которые требуются каждому контроллеру с [Authorize(Roles..., вы можете использовать [Authorize(Policy... чтобы добавить слой косвенности.

Таким образом, вы можете принять решение в своем StartUp класс (или в IConfigureOptions<AuthorizationOptions> сервис), именно то, что означает каждая политика. Включая любые другие странные требования, которые у вас могут возникнуть.

[Authorize(Policy= "Buyer")]
public class ProductController : ApiBaseController

...

services.AddAuthorization(o =>
{
    o.AddPolicy("Buyer", b => {
#if DEBUG
        b.RequireAuthenticatedUser();
#else
        b.RequireRole("Buyer");
#endif
    });
});

Я заставил его работать, используя приведенный ниже код, благодаря Джереми за правильное направление:

В классе контроллера я использовал авторизацию на основе политики:

 [Authorize(Policy= "Buyer")]
 public class ProductController : ApiBaseController
 {
 }

В start.cs мы можем добавить аутентификацию и авторизацию на основе условий ОТЛАДКИ:

#if !DEBUG
            services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
               .AddMicrosoftIdentityWebApi(config.GetSection("AzureAd"));
#endif

            services.AddAuthorization(options =>
            {
                // policy for read access
                options.AddPolicy("Buyer", policy =>
                {
#if DEBUG
                    policy.RequireAuthenticatedUser();
#else
                    policy.RequireRole("Buyer");
#endif
                });
            });

Для RequireAuthenticatedUser() в режиме отладки мы используем приведенный ниже код для добавления атрибута AllowAnonymous на всех контроллерах:

app.UseEndpoints(endpoints =>
            {
#if DEBUG
                endpoints.MapControllers().WithMetadata(new AllowAnonymousAttribute());
#else
                    endpoints.MapControllers();
#endif
            });