Re: PrincipalPermissionAttribute
From: Joe Kaplan (ilearnedthisthehardway_at_noway.com)
Date: 05/19/03
- Next message: Shel Blauman [MSFT]: "Re: Strong-name and remoting"
- Previous message: Glenn Wilson: "Re: Project Folder Not Secure"
- In reply to: Dave Sousa: "PrincipalPermissionAttribute"
- Next in thread: Dave Sousa: "Re: PrincipalPermissionAttribute"
- Reply: Dave Sousa: "Re: PrincipalPermissionAttribute"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 19 May 2003 11:00:39 -0500
I think the documentation on the PrincipalPolicy enumeration suggests that
by default, the current WindowsPrincipal is not associated with each thread
by the current AppDomain. This is changed by ASP.NET, but I think it is
left default by console and WinForms apps.
To get this to happen automatically, I believe you need to set the current
AppDomain's PrincipalPolicy to WindowsPrincipal:
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
;
(or something like that...)
It would be cool if you could do this with an assembly level attribute or
something, but I don't know if that is possible.
Give that a shot and let me know if it doesn't work. I'm curious about this
too.
Joe K.
"Dave Sousa" <XAYZBQMTRZSN@spammotel.com> wrote in message
news:024b01c31ce9$2403eaa0$a601280a@phx.gbl...
> I am running XP Pro with Framework 1.0. I have decorated
> a Windows Form class with the following attribute:
>
> [PrincipalPermissionAttribute(
> SecurityAction.Demand,
> Role=@"BUILTIN\Administrators")]
>
> This always fails with a security exception. I am in the
> Administrators group. Setting Authenticated=false in the
> attribute passes the security check.
>
> I then add the following code to the class constructor,
>
> AppDomain.CurrentDomain.SetPrincipalPolicy(
> PrincipalPolicy.WindowsPrincipal);
>
> and remove the PrincipalPermission attribute from the
> class definition.
>
> When I then add the PrincipalPermission attribute to a
> button onclick event, everything is authenticated as
> expected.
>
> I have seen many examples where the class definition is
> decorated with the PrincipalPermission attribute, and
> nobody seems to have a problem.
>
> My question is if the default principal is
> UnauthenticatedPrincipal, how can the class definition
> ever be decorated with an attribute that needs a
> WindowsPrincipal to check the role?
>
> Thanks,
>
> Dave
- Next message: Shel Blauman [MSFT]: "Re: Strong-name and remoting"
- Previous message: Glenn Wilson: "Re: Project Folder Not Secure"
- In reply to: Dave Sousa: "PrincipalPermissionAttribute"
- Next in thread: Dave Sousa: "Re: PrincipalPermissionAttribute"
- Reply: Dave Sousa: "Re: PrincipalPermissionAttribute"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]