Ended up with a custom IPrincipal and IIdentity that keeps track of the timeouts, as you suggested. If the PrincipalPermission accesses it via the Thread.CurrentPrincipal then it resets the timeout. Also put a timer in the authentication service in case they just wander off, it throws an exception which the view catchs and shows the login view.
Trying to force it to not use the Thread.CurrentPrincipal was causing me so much pain. As you said baked in (hard). thanks! Stephen On Thu, Mar 7, 2013 at 1:41 PM, Piers Williams <[email protected]>wrote: > 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 >>>> >>>
