My only worry about copying the onliners from Secure(Web)Page into MySecurePage is if they change. Every new wicket-security release we would have to check to make sure that nothing changed in Secure(Web)Page to prevent possible issues. I understand that the code is trivial and probably will not change significantly in the future, but the only true guarantee is only what is defined in the interface contract. I think a mount solution is worth further investigation. When I have time I will look into how to implement it (if possible). For now, I will live with the copy and paste and use your proposed solution. Thanks for your help! I will let you know how thinks turn out with ldap :o)
-----Original Message----- From: Maurice Marrink [mailto:[EMAIL PROTECTED] Sent: Monday, January 07, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: [wicket-security] LDAP integration? Do you mean that little bit of insignificant code in the Secure(Web)Page ? All that does is redirect to the SecureComponentHelper so i would not call that code duplication. Even more all SecureComponents i create use the same oneliners to redirect to SecureComponentHelper. Regarding the mount, i am not sure if you can get the mount path if all you have is a page class (you probably can somehow but i don't know how) In that case you can extend SwarmStrategy and use the mount path to check for instantiation permission. But i would not recommend that just to avoid "code duplication", if it really bothers you you can go ahead with option 2 and use a custom interface for instantiation checking. Or you could try and ignore the fact that the login page should not be a SecurePage and try it anyway, i am not a 100% sure it will work but i did make some exceptions that bypass the instantiation check if the page class in question is the login page, so give it a try. The reason the documentation says you should not have your login page extend SecurePage is because it just doesn't feel right to do so. Maurice On Jan 7, 2008 3:24 PM, William Hoover <[EMAIL PROTECTED]> wrote: > oops!!! > > *definitely* > > -----Original Message----- > From: William Hoover > Sent: Monday, January 07, 2008 9:23 AM > To: 'users@wicket.apache.org' > > Subject: RE: [wicket-security] LDAP integration? > > > The only issue I have with proposed solution 1 is that there is duplication > of code, but I cannot see a simple way around it. Is it plausible to adopt > the same strategy that we mount pages? I was thinking that doing something > like: > > mountSecurePage(MySecureWebPage.class) > > ...may be a nice alternative to actually extending SecureWebPage. > > I will defiantly contribute any ldap integration code once I am able to get > it working properly ;o) > > -----Original Message----- > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 05, 2008 12:16 PM > To: users@wicket.apache.org > Subject: Re: [wicket-security] LDAP integration? > > > You could do LoginPage extends AbstractBasePage > MySecurePage extends AbstractBasePage implements ISecurePage > OtherPage extends MySecurePage > > Or alternatively > MyInterface extends ISecurePage > AbstractBasePage extends SecureWebPage > LoginPage extends AbstractBasePage > OtherPage extends AbstractBasePage implements MyInterface > The important part here is the MyInterface > By default Swarm only does an instantiation check on components with > the ISecurePage interface (which is implemented by SecureWebPage). > But you can change this to any interface you like as long as the > interface extends ISecureComponent. > To do this you need to overwrite the setupStrategyFactory method of > SwarmWebApplication to do > setStrategyFactory(new SwarmStrategyFactory(MyInterface.class,getHiveKey())); > > Personally i would go for option 1 as you can simply copy the > implementation for ISecurePage from SecureWebPage > > BTW once you have the ldap part up and running and if it is setup in a > generic way i would be interested in including it with swarm or a > subproject if thats alright with you. > > Maurice > > On Jan 4, 2008 8:39 PM, William Hoover <[EMAIL PROTECTED]> wrote: > > I do have another question... > > > > According to the documentation one should not extend SecureWebPage for the > > login page (makes sense), but if you have a decorator that is used on all > > of your pages (including the login page) how can you accomplish this? For > > example: > > > > Example 1: > > AbstractBasePage extends SecureWebPage (wrapper) > > > > LoginPage extends AbstractBasePage (will not work) > > OtherPage1 extends AbstractBasePage > > OtherPage2 extends AbstractBasePage > > ... > > > > Example 2: > > AbstractBasePage extends WebPage (wrapper) > > > > LoginPage extends AbstractBasePage > > OtherPage1 extends ? (cannot extend both AbstractBasePage and SecureWebPage) > > OtherPage2 extends ? (cannot extend both AbstractBasePage and SecureWebPage) > > ... > > > > -----Original Message----- > > From: William Hoover [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, January 04, 2008 1:24 PM > > To: users@wicket.apache.org > > Subject: RE: [wicket-security] LDAP integration? > > > > > > Never mind... I wasn't calling super.init() when I was overriding init() in > > SwarmWebApplication impl > > > > -----Original Message----- > > From: William Hoover [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 04, 2008 1:14 PM > > To: users@wicket.apache.org > > Subject: RE: [wicket-security] LDAP integration? > > > > > > I'm with you... it doesn't seem to be too difficult to get the mapping > > between ldap/swarm working. I am attempting to try it out in a simple > > application. However, I am receiving a NullPointerException in WaspSession > > because the StrategyFactory is not instantiated. Is there something else > > that needs to be down in the SwarmWebApplication (following the > > instructions from > > http://wicketstuff.org/confluence/display/STUFFWIKI/Getting+started+with+Swarm)? > > > > public WaspSession(WaspApplication application, Request request) > > { > > super(request); > > securityStrategy = > > application.getStrategyFactory().newStrategy(); // throws npe > > } > > > > -----Original Message----- > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 04, 2008 11:16 AM > > To: users@wicket.apache.org > > Subject: Re: [wicket-security] LDAP integration? > > > > > > I think there will be one more beta before we do the final. > > I recently made some changes to boost performance and a public beta > > for that will be better. Even though we are already using it in our > > apps without problems through the snapshot release. > > With any luck the 2nd beta will be released this weekend and the final > > will probably follow soon after. > > > > Well the slightly more complex route is connecting to ldap yourself > > (option number 1 in my previous mail). > > Personally i think the mapping between ldap and swarm will be a > > breeze. because a swarm principal is basically just a name. > > > > Maurice > > > > On Jan 4, 2008 3:43 PM, William Hoover <[EMAIL PROTECTED]> wrote: > > > Thanks for the info. We are not using Spring (opted for Plexus) so I'm > > > not sure how plausible it will be to implement the easiest solution in > > > our case. The application in question is still in the preliminary > > > evaluation stage so we may have to look for another route. > > > > > > Do you have a roadmap/timeline on a release date for wicket-security? > > > > > > > > > -----Original Message----- > > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > > Sent: Friday, January 04, 2008 8:36 AM > > > To: users@wicket.apache.org > > > Subject: Re: [wicket-security] LDAP integration? > > > > > > > > > Yes and not exactly. > > > > > > wicket-security is build with plugability in mind, meaning if it does > > > not yet exist you can build it yourself quite easily. > > > Regarding LDAP, i myself have never worked with it but there are a > > > couple of options you can try > > > -use swarm and map ldap permissions to swarm principals > > > -use swarm with acegi and let acegi handle the ldap part, you still > > > need to map acegi permissions to swarm principals though but it saves > > > you from having to do all the ldap connection stuff yourself > > > -use wasp and build your own ldap implementation, more work but also > > > more control > > > > > > As for the ldap example part, i am afraid you are somewhat on your own. > > > There is however an example showing how to integrate swarm with acegi > > > http://wicketstuff.org/confluence/display/STUFFWIKI/Swarm+and+Acegi+HowTo > > > and there is an other example showing wicket-auth-roles acegi and ldap > > > http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html > > > So if you rip the ldap config from the last example and use it in the > > > first example instead of the TestingAuthenticationProvider you should > > > be ready to go > > > The example also has some suggestion on how you could do your own ldap > > > permission mapping if you choose to go that way. > > > > > > If you decide to go all out and build directly on wasp you should take > > > a look at swarm itself a a reference, just ignore all the stuff about > > > permissions, principals, subjects and stuff. > > > > > > Maurice > > > > > > On Jan 4, 2008 2:15 PM, William Hoover <[EMAIL PROTECTED]> wrote: > > > > Can wicket-security be used with LDAP? If so, are there any examples > > > > available demonstrating its use? > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
