Поставщик политики авторизации ASP.Net MVC в виде бритвы - PullRequest
Новая
       16

Поставщик политики авторизации ASP.Net MVC в виде бритвы

1 голос
/ 21 сентября 2019

Для некоторых приложений мне нужен пользовательский поставщик политики авторизации, который следовал по по этой ссылке и смог успешно создать тот, который работает в контроллере.Теперь, когда речь заходит о представлении, при авторизации на основе ролей вы можете просто использовать термин @if (User.IsInRole("SomeRole")) для отображения или скрытия элементов и ресурсов.

Как использовать настраиваемого поставщика политики авторизации в представлении для определенияесли определенный пользователь мог видеть материал, основанный на оценке политики?

Я искал в Интернете и не мог найти полезную информацию об этом, а также попытался поиграть с 

@if ((await AuthorizationService.AuthorizeAsync(User, "PolicyName")).Succeeded)

Ноэто также не увенчалось успехом - это тоже не политика.

Кто-нибудь делал это раньше?

Обновление

Я использую настраиваемый поставщик политики в контроллере следующим образом: 

[MinimumAgeAuthorize(15)]
public IActionResult Index()
{
       //some code
}

Я не могу сделать 

@if ((await AuthorizationService.AuthorizeAsync(User, "MinimumAgeAuthorize(15)")).Succeeded)

Что является эквивалентом для этого в виде бритвы?

1 Ответ

1 голос
/ 21 сентября 2019

Я не знаю, что у вас не получилось, но вот как вы можете использовать AuthorizationService.

Для этого примера давайте предположим, что вы определили политику при запуске: 

services.AddAuthorization(options =>
{
    // assume that claimtype of role is role.
    options.AddPolicy("MyRolePolicy", policy => policy.RequireClaim("role", "SomeRole"));
});

Это означает, что код, ограниченный «MyRolePolicy», доступен только тогда, когда у пользователя есть роль «SomeRole».Эквивалент User.IsInRole("SomeRole").

В представлении внедрите службу и протестируйте политику для пользователя: 

@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService _authorizationService

@if ((await _authorizationService.AuthorizeAsync(User, "MyRolePolicy")).Succeeded)
{
}

При использовании поставщиков политик пользовательской авторизации политики добавляются через промежуточное ПОНапример: 

public class AuthorizationPolicyProvider : DefaultAuthorizationPolicyProvider
{
    public AuthorizationPolicyProvider(IOptions<AuthorizationOptions> options) : base(options)
    {
    }

    public async override Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
    {
        // check static policies first
        var policy = await base.GetPolicyAsync(policyName);

        if (policy == null)
            return new AuthorizationPolicyBuilder().AddRequirements(new PermissionRequirement(policyName)).Build();

        return policy;
    }
}

В этом примере политики добавляются (если не существует) в качестве разрешения, где тип заявки - permission, а значение - имя политики.Когда я добавлю политику MyPermission, она проверит тип заявки permission со значением MyPermission.

В представлении: 

@if ((await _authorizationService.AuthorizeAsync(User, "MyPermission")).Succeeded)
{
}

Я не уверен, что вы имеете в виду«это тоже не политика», но поставщик политики авторизации возвращает политики.Таким образом, вы должны быть в состоянии проверить эти политики.Будь то простой тип заявки (например, разрешение или роль) или более сложная политика с параметрами.Но имя должно совпадать.Также убедитесь, что вы вводите необходимые обработчики, службы и т. Д.

Обновление

Вы также можете проверить, используя требования: 

@if ((await _authorizationService.AuthorizeAsync(User, null, new MinimumAgeRequirement(15))).Succeeded)

Где MinimumAgeRequirement - это само требование.

Как задокументировано : 

AuthorizeAsync(ClaimsPrincipal, Object, IEnumerable<IAuthorizationRequirement>)

Проверяет, соответствует ли пользователь определенному набору требований для указанного ресурса

...