Re: Resource authorisation scenario: dealing with non-application wide permissions
Danielle, I run out into the same problem. Did you solve it? if so, how? thanks in advance On Thu, Feb 11, 2010 at 11:50 PM, Daniele Dellafiore wrote: > Hi. > > Imagine this scenario: a webapp that allows creation of groups of people. > There is the owner, the administrator and the normal user for every group. > Like google groups, yahoo groups, facebook groups, a chat... a lot of > examples :) > > If we define permission as string concatenation, I can have "group:delete" > as permission. > In this scenario the permission is not application wide, but "group > specific". Is related to the entity of my domain: Group. > > Unfortunately I have no idea how to solve my problem in AuthStrategy, where > I can just access the user, not his particular Role in the specific group > of > my webapp, I do not have enough information. I can't know in > isActionAuthorized method what is the group to ask authorization access for > "group.delete" permission. > If I know which is the group (domain entity) I can ask the user for the > role > he has in the group, and see if it's role has "group.delete" permission. > Or any similar implementation, the point is that I miss an information. > > What can be a nice way to solve this problem with Wicket > AuthorizationStrategy? > > I have just read a recent article about how to integrate shiro and wicket: > http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html > > My point with that solution is that as far as I know, overriding > isVisible() > is a discouraged practice. More over, the visibility control for > authorisation access has better room in the AuthorizationStrategy and if I > remember fine, what change is the isVisibilityAllowed(). > > I can just figure out to to put that information (the role of the subject > in > the group) in the Action, but I have to learn how. Do you think should be a > nice idea? Or maybe I am making my life harder for nothing and setting > visibilityAllowed (or even override that method) would be fine enough? > > I think I can save a lot of "ifs" or a lot of override if I Can figure out > a > way to implement it the way I described. > > I will sleep on this :) > > -- > Daniele Dellafiore > http://danieledellafiore.net > -- Fernando Wermus. www.linkedin.com/in/fernandowermus
Re: Resource authorisation scenario: dealing with non-application wide permissions
your components are the ones that carry context, so... boolean isActionAuthorized(Component component, Action action) { if (component instanceof GroupAware) { Group group=((GroupAware)component).getGroup(); ... -igor On Thu, Feb 11, 2010 at 5:50 PM, Daniele Dellafiore wrote: > Hi. > > Imagine this scenario: a webapp that allows creation of groups of people. > There is the owner, the administrator and the normal user for every group. > Like google groups, yahoo groups, facebook groups, a chat... a lot of > examples :) > > If we define permission as string concatenation, I can have "group:delete" > as permission. > In this scenario the permission is not application wide, but "group > specific". Is related to the entity of my domain: Group. > > Unfortunately I have no idea how to solve my problem in AuthStrategy, where > I can just access the user, not his particular Role in the specific group of > my webapp, I do not have enough information. I can't know in > isActionAuthorized method what is the group to ask authorization access for > "group.delete" permission. > If I know which is the group (domain entity) I can ask the user for the role > he has in the group, and see if it's role has "group.delete" permission. > Or any similar implementation, the point is that I miss an information. > > What can be a nice way to solve this problem with Wicket > AuthorizationStrategy? > > I have just read a recent article about how to integrate shiro and wicket: > http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html > > My point with that solution is that as far as I know, overriding isVisible() > is a discouraged practice. More over, the visibility control for > authorisation access has better room in the AuthorizationStrategy and if I > remember fine, what change is the isVisibilityAllowed(). > > I can just figure out to to put that information (the role of the subject in > the group) in the Action, but I have to learn how. Do you think should be a > nice idea? Or maybe I am making my life harder for nothing and setting > visibilityAllowed (or even override that method) would be fine enough? > > I think I can save a lot of "ifs" or a lot of override if I Can figure out a > way to implement it the way I described. > > I will sleep on this :) > > -- > Daniele Dellafiore > http://danieledellafiore.net > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Resource authorisation scenario: dealing with non-application wide permissions
Hi. Imagine this scenario: a webapp that allows creation of groups of people. There is the owner, the administrator and the normal user for every group. Like google groups, yahoo groups, facebook groups, a chat... a lot of examples :) If we define permission as string concatenation, I can have "group:delete" as permission. In this scenario the permission is not application wide, but "group specific". Is related to the entity of my domain: Group. Unfortunately I have no idea how to solve my problem in AuthStrategy, where I can just access the user, not his particular Role in the specific group of my webapp, I do not have enough information. I can't know in isActionAuthorized method what is the group to ask authorization access for "group.delete" permission. If I know which is the group (domain entity) I can ask the user for the role he has in the group, and see if it's role has "group.delete" permission. Or any similar implementation, the point is that I miss an information. What can be a nice way to solve this problem with Wicket AuthorizationStrategy? I have just read a recent article about how to integrate shiro and wicket: http://blog.tauren.com/2010/01/using-wicket-with-shiro-for.html My point with that solution is that as far as I know, overriding isVisible() is a discouraged practice. More over, the visibility control for authorisation access has better room in the AuthorizationStrategy and if I remember fine, what change is the isVisibilityAllowed(). I can just figure out to to put that information (the role of the subject in the group) in the Action, but I have to learn how. Do you think should be a nice idea? Or maybe I am making my life harder for nothing and setting visibilityAllowed (or even override that method) would be fine enough? I think I can save a lot of "ifs" or a lot of override if I Can figure out a way to implement it the way I described. I will sleep on this :) -- Daniele Dellafiore http://danieledellafiore.net