Eelco Hillenius wrote:
>
>> Attempting to play with the application or Session AuthorizationStrategy
>> doesn't seem to be a good idea because it I would need to somehow inject
>> the
>> current page into the "Authorization Process".
>
> I think you are trying too hard to fit the existing authorization
> strategies, which in fact are meant as just examples, in your
> situation. To use those, you as you mention have to push the 'meta
> data' before rendering starts. But that's a pretty awkward programming
> model. What you should do is introduce some interface - like
> IMyAuthCheck { boolean hasAccess() } - and develop a custom strategy
> that checks whether a component implements this interface, and when it
> does, perform the check.
>
Man, you're reading my mind...freaky.
I realized I was forcing a square peg into a round hole and modified my
approach to be more like what you describe. I was stuck on the Auth
Strategy because I liked the way it worked. In that the components knew
that they were protected and the framework could just test the components,
no centralized facility to kept track of the security markers.
What I ended up doing (and am in the process of fleshing out, including the
naming) is make a MetaDataComponentProtector (modeled after the
MetaDataRoleAuthorizationStrategy). The idea is that you would mark a
component as "protected" and it would stick an ActionProtections class in
it's MetaData that contained a Map or Action (Render, Enable) /
commons-collections Predicate pairs. The Predicate is used to evaluate a
Component (specifically looking for an IProtectionVerifier as an ancestor to
the Component) to see if it has rights. But because it is a Predicate, any
number of Predicates can be combined together to make for a comprehensive
protection evaluation (I hope). In my case, I am making the containing Page
implement the IProtectionVerifer (with a hasRights(String role) method).
Now, to bring this all together, I use the Page's onBeforeRender method to
actually force the evaluation to occur. The MetaDataComponentProtector has
an updateComponent(Component) method that, depending on the Action, calls an
implementation of IComponentProtector (with a updateComponent(Component)
method) that knows how to modify a Component for the given Action. For
example, EnableProtector would perform the predicate eval and setEnabled(),
whereas the RenderProtector would setVisible. The point of the separate
IComponentProtectors is that there might end up being multiple Protectors
for a given action. Why? so that more specific modifications take place,
for example, AjaxLink when used with input=button doesn't actually make the
button appear disabled, it just blocks the onClick when isEnabled returns
false, so in this case, I would probably add a behavior to add the disabled
attribute.
I went through all that not only for your benefit :), but also because I
have a question. Currently, when I mark a component as protected, I add the
Component to a List on the Page (protectedComponents) so that onBeforeRender
doesn't have to go to every child Compoennt of the page (which could end up
being a pretty deep, dense tree) looking for protected components. Is
storing a List of Components bad? How expensive is it to traverse through
all children looking for a MetaDataKey?
On a related note, how expensive is it to look for a specifc type of Parent
of a Component?
Thanks, I know that was a lot to read, but I LOVE working with Wicket versus
the home-made solution that we currently use, but I need to build this kind
of stuff into the framewrok before I can unleash the rest of my team on it
and your help and insight are invaluable!
--
View this message in context:
http://www.nabble.com/Role-authorization-per-page-tf2453766.html#a6895441
Sent from the Wicket - User mailing list archive at Nabble.com.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
