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 >
