Реклама:

Использование метода IslnRoteß

<script runat="server"> protected void Page Load(object sonder, EventArgs e) {

if (Context.User,IsInRole("HR")) _linkHR.Visible = true;

i

</script>

Если до использования .NET вы разработали приложение не из среды ASP.NET (например, WinForms или Windows Services), возможно, вам целесообразнее применить другой подход. В подобных случаях принято использовать класс PrincipalPermis-siun и его соответствующий атрибут. Различие меж/(у использованием метода Demand класса Principal'Permission и прямым вызовом метода IsInRole состоит в том, что если в первом случае пользователь не принадлежит к данной роли, вызывается исключительная ситуация S ecunty Exception, однако класс PrincipalPe'rmission также вызывает метод IsInRole. Атрибут PrinàpalPermissionAttribute позволяет принимать решения по авторизации в декларативной форме. Несмотря на хорошее комментирование некоторых типов политики безопасности в исходном коде, следует все же учитывать, что этот атрибут требует унификации, то есть вам придется жестко закодировать имена ролей, а это не является оптимальным решением.

Использование класса PrtnclpalPermlsslon

I/ к этому методу могут обращаться только члены роли HR [PrincipalPermission(SecurilyAction.Demand, Role="HR")] public void GiveRaise(int amount) {

// Если значение больше 100.

// то пользователь должен также принадлежать к роли Management if (amount > 100) new PrincipalPermission(null, "Management").DemandO;

}

В приложениях ne из среды ASP.NET контекстом, естественно, является не Http-Context. Это означает, что класс PrincipalPermision должен полагаться на другое место хранения принципала текущего клиента, которым является статичное свойство CurrentPrincipal класса System.Threading.Thread, также относящееся к типу IPrincipal.

Для поддержки обоих стилей программирования ASP.NET задает Context.User и Thread.CurrentPrincipal во время обработки запроса. Это выполняется сразу после AuthenticateRequest в незадокументированном событии DefaultAuthentication. (Взгляните еще раз на пример ShowHandlers из главы 2, в котором отображается скрытое событие.) Модуль DefaultAuthenticationModule, который обрабатывает это событие, копирует текущее значение Context.User в Thread.CurrentPrincipal. Следует помнить, что если вы измените значение Context.User после AuthenticationRequesl (как в примере PostAuthenticate Request, который будет рассмотрен позже), то вам также придется вручную задать Thread.CurrentPrincipal. В противном случае оба принципала не будут синхронизированы, а метод Context.llser.lsInRole может вернуть результаты, отличные от результатов метода Principal Permission. Demand.

rj ПРИМЕЧАНИЕ В ASP.NET вы будете чаще иметь дело со стилем Context.UserJslnRole, чем со стилем PrincipalPermission. Тем не менее PrincipalPermission представляет «родную» защитную инфраструктуру NET на основе ролей. По умолчанию это '«просто работает», и если вы будете помнить, что вам самому нужно задать Thread.CurrentPrincipal при изменении значения Context.User после выполнения AuthenticationRequesl, то вам не придется выполнять особые действия для включения PrincipalPermission (то есть не требуется и даже не рекомендуется вызывать метод AppDomain.SetPrincipaiPolicy).


⇐ Предыдущая страница| |Следующая страница ⇒