Re: Custom Attribute
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 step...@perthprojects.com 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
Re: Custom Attribute
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 piers.willi...@gmail.com 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 step...@perthprojects.com 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
Re: Custom Attribute
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 step...@perthprojects.com 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 piers.willi...@gmail.com 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 step...@perthprojects.com 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
Re: Custom Attribute
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 piers.willi...@gmail.comwrote: 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 step...@perthprojects.com 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 piers.willi...@gmail.com 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 step...@perthprojects.com 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
Re: Custom Attribute
I was playing with Attributes to understand when they were created and found they were only created when someone looked for them. So I'd guess you'd need to ensure something does reevaluate the attribute. I'd guess you might have to mark the attribute, or its usage, in some way as not permanent for code access purposes. On 4 March 2013 13:47, Stephen Price step...@perthprojects.com 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 -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.)
Custom Attribute
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
