I have a service that holds the current logged in user. To get the principal permission to work you have to set the thread.currentprincipal which does work. I want to be able to tell the difference between a login timing (by my service) out versus a user not in the right role. Actually explaining that has given me an idea to try. Obviously happy to not write bit myself if I can cover the behavior I want from it Thanks On Mar 6, 2013 10:32 PM, "Piers Williams" <[email protected]> wrote:
> CAS doesn't need to be reevaluated, since the evidence won't have changed. > So you have probably started on the wrong place. I think > PrincipalPermissionAttribute is sealed by design because its support is > kinda baked into the runtime (don't quote me on that). > > Rather than trying to frig the security system, why not implement a custom > principal and handle the role check there? > On 4 Mar 2013 11:17, "Stephen Price" <[email protected]> wrote: > >> Hey all, >> >> I've written a custom attribute that duplicates the behaviour of >> PrincipalPermissionAttribute (It checks the user roles against my own >> Authentication service instead of looking at the Thread.CurrentPrincipal) >> >> I've noticed that it works but only seems to check the first time you >> access the method its decorating. Its like it assumes it has permission >> first time so will have access from then on. Problem being if the user logs >> out and logs back in as someone who isn't in the correct role, it doesn't >> check and lets them in when if it were to check, it would fail. >> >> Is there some kind of message or something to signal that the >> CodeAccessSecurityAttribute (the one i'm inheriting as >> PrincipalPermissionAttribute is sealed) should reevaluate it? Not even sure >> what to search for on Google... I've found a couple of similar >> implementations but nothing mentions this issue that I've found. >> >> cheers, >> Stephen >> >
