Question - I came across the terms Swarm and Wasp a while ago, but didn't see them mentioned in Wicket In Action in the Security chapter. I've been using the book as sort of my starting point for writing JSecurity's integration. Are these other things no longer used?
I mentioned in my previous email the interfaces I'm implementing. Should I be looking at other things as well? Thanks, Les On Tue, Oct 14, 2008 at 11:35 AM, James Carman <[EMAIL PROTECTED]> wrote: > It probably shouldn't remain in an apache package, since it's not > officially an apache project. > > On Tue, Oct 14, 2008 at 11:29 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> i dont think any of us have time and energy to take on another core module >> that we would have to keep in sync with jsecurity. >> >> i suggest putting it in wicketstuff first and letting it mature there for a >> while. we can always reevaluate later. >> >> -igor >> >> On Tue, Oct 14, 2008 at 7:44 AM, Maarten Bosteels >> <[EMAIL PROTECTED]>wrote: >> >>> 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] >>> > >>> > >>> >> > > --------------------------------------------------------------------- > 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]
