IAuthorizationStrategy is pretty darn easy to use and really suffers
from none of the problems you described. in your application's
constructor you would do something like this:
getSecuritySettings().setAuthorizationStrategy(new
IAuthorizationStrategy()
{
boolean authorizeInstantiation(Class componentClass)
{
if (! <check-authorization(componentClass)>) // could be
annotations or instanceof equivalent or whatever
{
throw new RestartResponseAtSignInPageException();
}
return true;
}
boolean authorizeAction(Component component, Action action)
{
return true;
}
});
and you also have to register a sign in page class in your
ISecuritySettings. when the given component (Page in this case)
instantiation is attempted, the Component constructor will
immediately call your authorization strategy's authorizeInstantiation
() method (before anything significant has happened). You can return
true or false, or you can throw a
RestartResponseAtSignInPageException, which will redirect to a sign-
in intercept page to allow the user to authenticate themselves before
continuing where they left off trying to access.
if we want to make this super easy, we could create an Abstract base
class for this which lets you just implement the check and not worry
about the rest of it. in fact, i think i'll do that... ;-)
jon
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
