You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jürgen Lind <Ju...@iteratec.de> on 2012/04/21 09:51:20 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AuthorizationStrategy design question
Posted by Jürgen Lind <Ju...@iteratec.de>.
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 Lind<Ju...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
>
--
Mit freundlichen Grüßen,
Jürgen Lind
--
Dr. Jürgen Lind
iteratec GmbH Fon: +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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AuthorizationStrategy design question
Posted by Martin Grigorov <mg...@apache.org>.
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 <Ju...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org