That won't be so easy. It would break the API, unless we make couple of 
ugly hacks.

-Matej

Mats Norén wrote:
> Consider backporting it to 1.2 as well... :)
> 
> /Mats
> 
> On 8/11/06, Stefan Arentz <[EMAIL PROTECTED]> wrote:
>> 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
>>
> 
> -------------------------------------------------------------------------
> 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
> 


-------------------------------------------------------------------------
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

Reply via email to