Почему мы должны выбирать PrincipalPermission вместо IsInRole ()?

Question

Q1 - я не уверен, что понимаю, почему мы должны использовать PrincipalPermission.Union () (или PrincipalPermission.Intersect () ) вместо IsInRole ( ) ? Во всяком случае, для вызова IsInRole () несколько раз требуется меньше кода, чем для создания нескольких PrincipalPermission объектов и объединения их в один с помощью Union () (или Intersect () )?

Q2 - одна перегрузка конструктора объекта PrincipalPermission также указывает флаг IsAuthenticated , который сообщает Demand () , чтобы проверить, аутентифицирован ли пользователь. Разве этот флаг не будет полезен только в тех случаях, когда первые два параметра ( name и role ) равны нулю?

1038 * спасибо *

Answer 1

Q1. - RE: методы PrincipalPermission и IPrincipal.IsInRole (..)

Два вызова функций создают PrincipalPermission, который имеет объединение или пересечение ролей, которые вы ему предоставляете. Таким образом, вы получаете принципала, который имеет очень специфический набор требований, который вы затем можете вызывать IsInRole (). Обратите внимание, что при этом будет затронут ваш поставщик ролей, который может быть сервером SQL или активным каталогом и, следовательно, будет иметь место задержка, поэтому вы не хотите делать это все время.

Q2. - RE: проверка подлинности PrincipalPermission

Аутентифицированный означает, что пользователь вошел в систему с вашим провайдером. Вы можете захотеть этого, если вам нужен только аудит вашего приложения, подтверждение того, что пользователь вошел в систему вашего поставщика ролей, будет означать, что вы можете регистрировать, кто они и т. Д.

Вы правы, говоря, что это полезно только в том случае, если вас не волнует, кто пользователь, а только то, что он вошел в систему.