I'm running into a situation where the IAuthorizationStrategy
interface is not sufficient enough. What I would like to propose is to
change:
boolean isInstantiationAuthorized(Class componentClass);
to:
boolean isInstantiationAuthorized(Class componentClass Object[]
arguments);
This way an authorization strategy can capture the whole page request
and eventually redirect the user back to the original page that was
requested.
A little example will probably explain better.
Say we have a secure page like this:
public abstract MyAuthenticatedWebPage extends WebPage {
...
}
public class EditProfilePage extends MyAuthenticatedWebPage {
EditProfilePage() {
...
}
}
Intercepting this page with a IAuthorizationStrategy is simple:
class MyAuthorizationStrategy implements IAuthorizationStrategy
{
public boolean isInstantiationAuthorized(Class componentClass)
{
if
(MyAuthenticatedWebPage.class.isAssignableFrom(componentClass)) {
// Remember the page that was requested
session = ...
session.setRequestedAuthenticatedPage(componentClass);
// Show the login form - which will redirect back to the
original page after login
throw new
RestartResponseAtInterceptPageException(LogInPage.class);
}
return true;
}
public boolean isActionAuthorized(Component component, Action
action)
{
return true;
}
}
Somewhere in the LogInPage we can get back to the original page like this:
session = ...
Class responsePage = session.getRequestedAuthenticatedPage();
if (responsePage == null) {
responsePage = SomeHomePage.class;
} else {
session.setRequestedAuthenticatedPage(null);
}
setResponsePage(responsePage);
This is probably a pretty well known wicket pattern.
The problem is, it stops working when the page you want to protect
needs constructor arguments. Which is not an uncommon situation.
For example:
public class ShowSomeStuffByCountryPage extends MyAuthenticatedWebPage {
ShowSomeStuffByCountryPage(Country country) {
...
}
}
There is no way to protect this page using IAuthorizationStrategy
since the page arguments (Country) get lost.
So, the proposed change will result in two improvements:
* The IAuthorizationStrategy can make a decision based not on just
the Page's class but also on the arguments to that Page. This will
allow for some more interesting advanced authorization schemes.
* In case the IAuthorizationStrategy does the 'redirect to login page
and back to original page' thing, it can remember the whole request -
no information is lost.
If this sounds like a useful improvement then I would like to
implement this in the Wicket 2.0 tree this weekend.
I've been wanting to contribute to Wicket for a long time and I think
this is a good start.
If people here agree, what is a good way to do this? Shall I make a
patch and put that online so that the committers can look at it? How
does that process work for this project?
:-)
S.
-------------------------------------------------------------------------
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-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
