Re: AuthorizationStrategy design question
Hi Juergen, How do you get the component path ? I guess you talk about org.apache.wicket.authorization.IAuthorizationStrategy#isInstantiationAuthorized(Class) which receives a Class as parameter, not a Component. So I don't see how you get the component path from that class. If you are able to get the component path then you should be able to do: component.findParent(ListPanel1.class) != null. This is possible for org.apache.wicket.authorization.IAuthorizationStrategy#isActionAuthorized(Component, Action) I'm not sure why IAuthorizationStrategy#isInstantiationAuthorized() accepts a Class as parameter while even the component is available: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L280 On Sat, Apr 21, 2012 at 10:51 AM, Jürgen Lind juergen.l...@iteratec.de wrote: Hi, I am looking for ideas on how to implement a context-aware AuthorizationStrategy. This means that I need a way to decided whether a certain self-written component can be instantiated in a particular context or not. For example, the filter component may be show to a user with a certain permission when looking at ListPanel1, but not when looking at ListPanel2. In previous Wicket applications, a have use my own annotation-based scheme that worked very well, but I cannot use it for this application since the permission granularity is much more fine-grained and context sensitive. Is there any good way of doing this? I already tried looking at the component path, but that does not give me the information I need since it only covers the ids of the components i.e. using the above filter component in a setting where ListPanel1 and ListPanel2 are switched via Ajax calls, I get the same component path... Thanks for any ideas, J. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AuthorizationStrategy design question
Hi Martin, actually, I was talking about '#isActionAuthorized' of my IAuthorizationStrategy. There, I have access to the component and the path. However, the problem remains that the path is identical whenever the parent components are replaces by one another. I have now taken the following approach: * I have an annotation AuthorizationContext that can be attached to any component in the component hierarchy * In '#isActionAuthorized' I scan the component hierarchy until an AuthorizationContext is found * If one is found, I have a Datastructure (specified as XML Document) that tells me which permissions are required for a specifiy component id in the given context. Seems to work thus far and still nicely separates the authorization stuff from the rest on the application... Cheers, J. On 23.04.2012 09:36, Martin Grigorov wrote: Hi Juergen, How do you get the component path ? I guess you talk about org.apache.wicket.authorization.IAuthorizationStrategy#isInstantiationAuthorized(Class) which receives a Class as parameter, not a Component. So I don't see how you get the component path from that class. If you are able to get the component path then you should be able to do: component.findParent(ListPanel1.class) != null. This is possible for org.apache.wicket.authorization.IAuthorizationStrategy#isActionAuthorized(Component, Action) I'm not sure why IAuthorizationStrategy#isInstantiationAuthorized() accepts a Class as parameter while even the component is available: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L280 On Sat, Apr 21, 2012 at 10:51 AM, Jürgen Lindjuergen.l...@iteratec.de wrote: Hi, I am looking for ideas on how to implement a context-aware AuthorizationStrategy. This means that I need a way to decided whether a certain self-written component can be instantiated in a particular context or not. For example, the filter component may be show to a user with a certain permission when looking at ListPanel1, but not when looking at ListPanel2. In previous Wicket applications, a have use my own annotation-based scheme that worked very well, but I cannot use it for this application since the permission granularity is much more fine-grained and context sensitive. Is there any good way of doing this? I already tried looking at the component path, but that does not give me the information I need since it only covers the ids of the components i.e. using the above filter component in a setting where ListPanel1 and ListPanel2 are switched via Ajax calls, I get the same component path... Thanks for any ideas, J. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AuthorizationStrategy design question
Hi, I am looking for ideas on how to implement a context-aware AuthorizationStrategy. This means that I need a way to decided whether a certain self-written component can be instantiated in a particular context or not. For example, the filter component may be show to a user with a certain permission when looking at ListPanel1, but not when looking at ListPanel2. In previous Wicket applications, a have use my own annotation-based scheme that worked very well, but I cannot use it for this application since the permission granularity is much more fine-grained and context sensitive. Is there any good way of doing this? I already tried looking at the component path, but that does not give me the information I need since it only covers the ids of the components i.e. using the above filter component in a setting where ListPanel1 and ListPanel2 are switched via Ajax calls, I get the same component path... Thanks for any ideas, J. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
