Я думаю, вам нужно создать больше контекста о потребностях приложений.может быть много последствий для group
и dynamic
.
В мире аутентификации, по моему опыту, группы предназначены для защиты данных или даже безопасности на уровне строк.Так что больше информации нужно здесь.но это абстракция, каждое приложение может решить, что на самом деле означает этот термин в коде.
Если вы хотите перерезать представления, я бы предложил использовать политики, у них есть возможности времени выполнения, и вы можете сохранить их в своей базе данных исделать общее использование.
Как их назначить?это действительно зависит от вашего приложения ... может быть много вариантов использования.
- ваш пользователь присоединяется сам, вам нужно сохранить его в базе данных с политикой.
- ваш пользователь создан кем-то еще в приложении, вы можете присоединить его к политике или поддержать его в пользовательском интерфейсе.
- используйте, чтобы получить больше доступа по прошествии времени ... опять же, вы должны решить, будет ли это автоматически или нет ...
вот пример, как ограничить вручную:
public class ContentController : Controller
{
private IAuthorizationService _authorizationService;
public ContentController (IAuthorizationService authorizationService)
{
_authorizationService = authorizationService;
}
public async Task<IActionResult> Save(Article article)
{ var allowed = await _authorizationService.AuthorizeAsync(User, "ContentsEditor"));
if (!allowed)
throw new SomeAuthException();
// ok, goot to go....
...
}
}
у вас есть более «инфраструктурные» способы реализации этого, но это только пример
Пожалуйста, ознакомьтесь с рекомендациями по использованию политики: https://www.jerriepelser.com/blog/creating-dynamic-authorization-policies-aspnet-core/