Have a role in your system called 'loginsIsCurrent' or something. But the PrincipalPermission attribute is a fairly blunt tool - if you need to react differently you probably need imperative checks anyway. In which case all this is moot. On 7 Mar 2013 07:06, "Stephen Price" <[email protected]> wrote:
> 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 >>> >>
