Hello Les, Great news ! No idea where these files should go.
I guess wicket-core shouldn't depend on jsecurity and vice versa, right ? So maybe you could add it to wicket-stuff ? That's also where the Wicket-Acegi examples are located AFAIK. But I have the feeling that the quality and level of maintenance varies greatly between wicket-stuff projects. What do the wicket core devs think ? In the meantime it would be super if you could send the files directly to [EMAIL PROTECTED] Thanks, Maarten On Tue, Oct 14, 2008 at 3:01 AM, Les Hazlewood <[EMAIL PROTECTED]>wrote: > Hi Maarten, > > So far things are going great - it took almost no time at all to > integrate the two projects, which I consider a reflection of the good > design of both architectures ;) > > I have a few classes created that basically recreates the SignIn* > classes in chapter 11 of Wicket In Action to show how to login/logout > and show/hide links based on a users login state using the JSecurity > API. I've already licensed them to the ASF and can put them wherever > you like. They're currently in the org.apache.wicket.jsecurity > namespace, but only as a place holder. How would you like to receive > these files? > > I'm in the process of finishing the authorization support - JSecurity > specific implementations of IAuthorizationStrategy > IUnauthorizedComponentInstantiationListener. They're pretty slick - > they look for JSecurity's existing annotations in classes > (@RequiresAuthentication, @RequiresUser, @RequiresGuest, > @RequiresRoles, @RequiresPermissions) and allow creation or access > accordingly. Pretty nice :) > > The one final thing to do is to investigate whether or not I'll need > to create an ISessionStore implementation to access the JSecurity > Session API directly. This allows clustered/distributed-cached > sessions, single sign on, and heterogeneous client session access. > That won't take too long, I just have to see what it entails. > > Let me know how you'd like to receive the files, and I'll send > them/place them where you want. In the meantime, I'm going to finish > up the Authorization and Session support.... > > Cheers, > > Les > > On Mon, Oct 13, 2008 at 4:10 PM, Maarten Bosteels > <[EMAIL PROTECTED]> wrote: > > Hello Les, > > > > On Thu, Sep 25, 2008 at 5:11 PM, Les Hazlewood <[EMAIL PROTECTED] > >wrote: > > > >> Haha, funny you should ask this - I'm doing it now ;) > > > > > > Well, it wasn't pure coincidence: I saw your name appearing on the wicket > > mailing-list a few weeks ago and I was kinda hoping for this answer ;-) > > > > > > > >> I've recently started > >> using Wicket for my latest web application, and naturally I wanted to do > >> this. I'll have to do a little write-up when I'm finished with it. > > > > > > Do you have any idea when we can see some of that stuff ? > > > > > >> Any questions that I could help with in particular in the meantime? > > > > > > Not yet, I haven't really looked into it yet. > > > > Thanks, > > Maarten > > > > > > > >> > >> Naturally, I would hope that JSecurity would be one of the core > supported > >> or > >> maybe even 'default' security mechansim for Wicket in the future, now > that > >> JSecurity is a part of the ASF. I'll certainly help to that effort if > it > >> is > >> desired! > >> > >> Cheers, > >> > >> Les > >> (JSecurity founder) > >> > >> On Thu, Sep 25, 2008 at 11:05 AM, Maarten Bosteels > >> <[EMAIL PROTECTED]>wrote: > >> > >> > Hi, > >> > > >> > Anyone tried integrating Wicket with JSecurity ? > >> > > >> > http://www.jsecurity.org/ > >> > > >> > Maarten > >> > > >> > On Thu, Sep 25, 2008 at 4:54 PM, James Carman > >> > <[EMAIL PROTECTED]> wrote: > >> > > You can bridge the gap between Spring Security's default URL-based > >> > > model and the component-based model in Wicket. That's what we do > here > >> > > at work. If you want an example, let me know. I've got one out > there > >> > > on my public example stuff somewhere. You could try poking around > in > >> > > (I think it's there): > >> > > > >> > > http://svn.carmanconsulting.com/public/wicket-advanced/trunk > >> > > > >> > > > >> > > On Thu, Sep 25, 2008 at 10:51 AM, Claus Myglegaard Vagner > >> > > <[EMAIL PROTECTED]> wrote: > >> > >> Hi, > >> > >> > >> > >> I'm about to start a new project using Wicket and is currently > >> examining > >> > >> which security framework to apply for. I'm looking for best > practices > >> > >> implementing security to a Wicket application. > >> > >> > >> > >> Wicket has WASP which Swarm is an implementation of and then there > is > >> > >> wicket-auth-roles. Is wicket-auth-roles related to WASP in any way > or > >> is > >> > >> it a completely different security platform for wicket? > >> > >> > >> > >> Which security framework will be the future for wicket? > >> > >> > >> > >> I am thinking on using Spring Security (prior Acegi) for securing > the > >> > >> service layer through aspects. Spring Security has build in > >> > authentication > >> > >> integration with various technologies like LDAP and for example a > >> > >> "remember me" function. I'm thinking that this project should > benefit > >> > from > >> > >> this built in functionality, but maybe the wicket frameworks has > some > >> of > >> > >> the same possibilities? > >> > >> > >> > >> Well, should I integrate Spring Security to Swarm or > wicket-auth-roles > >> > and > >> > >> what would that give me? I know that Spring Security is url based > and > >> > >> Swarm is component based, but not sure yet that I need to specify > >> > security > >> > >> on the component level. > >> > >> > >> > >> Regards Claus > >> > >> > >> > >> > --------------------------------------------------------------------- > >> > >> 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] > >
