By looking at the source code it looked very nice (and you're right about complex, but of course you are doing lots of important things so it's hard not to have something complex) to me. You seem to be very knowledgable.
I didn't get it working in Eclipse though. I did a svn co <the trunk path you gave me>, and then I tried mvn eclipse:ecilpse. It complained about missing jta.jar and failed, I fixed it (I think it's a license problem so it doesn't get downloaded by Maven) and could run mvn eclipse:eclipse successfully. I imported the project into my workspace in Eclipse, added my Tomcat server under the Servers tab. But the project was of wrong type (I think), so I couldn't add the project to be deployed in my server from Eclipse. Then I tried creating the war-file by mvn war:war, it worked and I did a deploy by copy. But it wouldn't start. Best regards, Kent On Tue, Mar 10, 2009 at 7:25 PM, James Carman <[email protected]> wrote: > My wicket-advanced demo code integrates Spring Security and Wicket > using wicket-auth-roles: > > http://svn.carmanconsulting.com/public/wicket-advanced/trunk/ > > The key is the SpringSecuritySession class: > > http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/java/com/carmanconsulting/wicket/advanced/web/common/session/SpringSecuritySession.java > > > On Tue, Mar 10, 2009 at 1:42 PM, Kent Larsson <[email protected]> wrote: >> Integrating with jSecurity instead is really a last resort. If it is >> at all possible I wouldn't like to introduce more framework >> dependencies. That integration project seems a bit early to use as >> well, but it might be interesting in the future. Thanks for the link! >> >> Regarding Spring Security (SS). Is anyone integrating Wicket with SS >> on their own? I've read lots about SS now but I still find it hard to >> see what I need for a Wicket application. >> >> I got some tips at: >> http://wiki.apache.org/tapestry/Tapestry5AcegiNoAnnotations >> >> But I still have lots of questions. >> - In the above link they are using a link and passing the information >> by GET. I would like to use POST, and I guess that shouldn't be a >> problem. Tell me if you see some? >> - I have to instruct SS to redirect a user to my own login page if >> (s)he tries to access something which requires authentication. How is >> that done? >> - When a user registers an account I guess I should pass something on >> to a servlet filter, similar to how authentication works? >> - Which servlet filters do you think I'll need? >> >> If I can just get someone to register and authenticate. Then I'll just >> use the instructions in SS documentation to get GrantedAuthority >> objects. I'll use these to show/hide things in Wicket pages as well as >> enable/disable other things. Does that sound like a good approach? >> >> If anyone has *any* tips I would be immensely greatful!! As I think >> this is quite complex and I'm new to Spring Security. >> >> Best regards, >> Kent >> >> >> On Mon, Mar 9, 2009 at 7:16 PM, Ryan McKinley <[email protected]> wrote: >>> I have not used it (yet), but check: >>> http://code.google.com/p/wicket-jsecurity/ >>> >>> >>> >>> On Mar 9, 2009, at 1:46 PM, Kent Larsson wrote: >>> >>>> Hm, I had some problems. Are there any examples out there for this? >>>> >>>> On Mon, Mar 9, 2009 at 9:43 AM, Kent Larsson <[email protected]> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Great answer! :-) I'll try to do that today. >>>>> >>>>> Best regards, Kent >>>>> >>>>> >>>>> On Sun, Mar 8, 2009 at 8:38 PM, Erik van Oosten <[email protected]> >>>>> wrote: >>>>>> >>>>>> Hi Kent, >>>>>> >>>>>> Go with something that enables authorization in the service layer (e.g. >>>>>> Spring Security, jSecurity, ...). >>>>>> >>>>>> Next base your custom wicket authorization on the authentication store >>>>>> of >>>>>> the chosen base technology. Spring Security uses a thread local as >>>>>> authentication store and has a servlet filter to copy the authenticated >>>>>> user >>>>>> to/from the session so that the authenticated user is handily available >>>>>> during a request and properly stored afterwards. >>>>>> >>>>>> Authentication itself can be implemented from Wicket in a custom way >>>>>> (e.g. a >>>>>> username/password form). On success you just store the authenticated >>>>>> user in >>>>>> the authentication store. >>>>>> >>>>>> Regards, >>>>>> Erik. >>>>>> >>>>>> >>>>>> Kent Larsson wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I know there has been some discussion on this. But I've had a hard >>>>>>> time deciding how this project should use security anyway. >>>>>>> >>>>>>> The application in question is layered into three layers for >>>>>>> presentation, services and persistence using Wicket, Spring and >>>>>>> Hibernate. >>>>>>> >>>>>>> What we need: >>>>>>> - Authentication >>>>>>> - Authorization on pages, components >>>>>>> - Authorization before being able to run methods in the service layer >>>>>>> - Authorization for viewing/editing some domain objects using Access >>>>>>> Control List's (ACL's) >>>>>>> >>>>>>> I have read Wicket in Action and it's custom security solution has some >>>>>>> pros: >>>>>>> - It's quite easy to understand >>>>>>> - We have a lot of freedom in how to do authentication and >>>>>>> authorization >>>>>>> >>>>>>> And some cons: >>>>>>> - I don't know how to authorize calls of specific methods, and thus >>>>>>> - All security will be in the presentation layer >>>>>>> - It won't be usable if we want security on web services later (which >>>>>>> we do not need now, so maybe this can be disregarded) >>>>>>> >>>>>>> It would be nice if we could have a common solution to our security >>>>>>> needs that integrates well with Wicket and Spring. I know that the >>>>>>> Auth Roles project is out there as well as Swarm. But I don't know >>>>>>> which will meet our needs and which will most likely be an option to >>>>>>> us when we later move to Wicket 1.4 or a higher version. >>>>>>> >>>>>>> Best regards, >>>>>>> Kent >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Erik van Oosten >>>>>> http://www.day-to-day-stuff.blogspot.com/ >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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]
