Re: Spring Security 3 and Wicket
Hi Dmytro, My point is to use authentication and authorization provided by SS 3 and Wicket as a great component framework. P.S. I'm not going to use Apache Shiro, because it doesn't suite my needs. Why doesn't Apache Shiro suit your needs? AIUI, Shiro can do all that Spring Security can do, and more. I ask not to create a 'Shiro vs SS' thread, but to better understand so that Shiro can become better by ensuring it supports what you need. Thanks, Les (Apache Shiro team) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket + security, what are the best options? Spring Security reached almost all the way...
Just a quick note to Wicket and Wicket-Stuff Shiro users: Shiro 1.0 is right around the corner. We should be code-complete for 1.0 in a day or two and then we being the ASF voting process to release the software. A concrete (non snapshot) release is coming very soon! Best, Les - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket + security, what are the best options? Spring Security reached almost all the way...
If it's any consolation, we only have a few remaining issues in Jira that should be finished today and tomorrow. 4 months ago, there was still over 50+ issues to resolve ;) Security frameworks are hard to get right - better to have a great 1.0 release than a crappy one :) On Tue, May 11, 2010 at 12:59 AM, Martin Grigorov mcgreg...@e-card.bg wrote: On Mon, 2010-05-10 at 23:32 -0700, Les Hazlewood wrote: Just a quick note to Wicket and Wicket-Stuff Shiro users: Shiro 1.0 is right around the corner. We should be code-complete for 1.0 in a day or two and then we being the ASF voting process to release the software. A concrete (non snapshot) release is coming very soon! Best, Les You said the same 4 months ago ;-) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: webapp authentication
Hi Martin, Thanks for the feedback! To clarify for other users, it is (now) pretty clear how to perform configuration and configure Realms via the link I sent in my last mail - please read it if you want to give it a try again. Maybe this was written after you tried Shiro, but at least it is well documented now for everyone :) Best regards, Les On Thu, Feb 4, 2010 at 2:32 AM, Martin Asenov mase...@velti.com wrote: Hi again , Les! Well, here my recommendations come. By saying simple setup I mean creating a single realm that extends AuthorizingRealm and configuring a web security manager that uses that realm. That's all I need. I found nowhere in the sample projects such thing, even in the spring-hibernate project. For me it looks like the configuration of the realm there is not entirely written. Appreciate your interest! Best Regards, Martin -Original Message- From: les.hazlew...@anjinllc.com [mailto:les.hazlew...@anjinllc.com] On Behalf Of Les Hazlewood Sent: Wednesday, February 03, 2010 6:56 PM To: users@wicket.apache.org Subject: Re: webapp authentication Hi Martin, What do you mean by you couldn't set Shiro up? Did you mean shiro-wicket in wicketstuff? Or just Shiro's out-of-the-box web support? Setting up Shiro for any webapp is as painless as possible: http://cwiki.apache.org/confluence/display/SHIRO/Web Of course, any recommendations are appreciated. Cheers, Les On Wed, Feb 3, 2010 at 10:25 AM, Martin Asenov mase...@velti.com wrote: Hello guys! I want to ask you which security frameworks you use when it comes to authenticating users through JPA. I relied on JSecurity/Shiro but I can't set it up. I'm looking for a simple framework but secure enough (not looking for extraordinary security), which I can set pretty easily with my database that holds my custom User objects. Please give me some suggestions. Thanks! Regards, Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: webapp authentication
Hi Martin, What do you mean by you couldn't set Shiro up? Did you mean shiro-wicket in wicketstuff? Or just Shiro's out-of-the-box web support? Setting up Shiro for any webapp is as painless as possible: http://cwiki.apache.org/confluence/display/SHIRO/Web Of course, any recommendations are appreciated. Cheers, Les On Wed, Feb 3, 2010 at 10:25 AM, Martin Asenov mase...@velti.com wrote: Hello guys! I want to ask you which security frameworks you use when it comes to authenticating users through JPA. I relied on JSecurity/Shiro but I can't set it up. I'm looking for a simple framework but secure enough (not looking for extraordinary security), which I can set pretty easily with my database that holds my custom User objects. Please give me some suggestions. Thanks! Regards, Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Future of Wicket Security (WASP/SWARM)
[ ] adopt Wicket security into Apache Wicket [x] keep Wicket security at Wicket Stuff I am biased, yes, but I much prefer Shiro in my Wicket apps too :) - Les On Fri, Jan 22, 2010 at 10:03 AM, Martin Grigorov mcgreg...@e-card.bg wrote: On Fri, 2010-01-22 at 10:52 +0100, Martijn Dashorst wrote: Guys, I'd like to discuss the future of the Wicket Security project. Currently the project lives on/in the wicketstuff repository, but uses group id and package names org.apache.wicket. IMO We should either: - adopt Wicket Security into the Wicket project and move everything over from Wicket Stuff into a subproject within Apache Wicket (and adopt the committers), or - keep Wicket Security at wicketstuff and move it into the fold of wicket stuff, including groupid/package rename. Since development on wicket security 1.4 is currently happening with a 1.4-beta1 just released, it is prudent to decide its future now (with a pending package rename). Considering that both the wicket security contributors and the Wicket PMC members are needed to make this happen, all their opinions are considered binding. [ ] adopt Wicket security into Apache Wicket [x] keep Wicket security at Wicket Stuff I haven't seen in the mailing lists many users of it. Most of them use Spring Security (my statistics). I think there is no need to add one more thing to support by the core committers. P.S. I personally prefer Shiro. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket security future - contribute!
Just a quick note to those interested - the Shiro dev team is trying very hard to get a 1.0 final release out hopefully before the end of this month. Best, Les (Apache Shiro team) On Thu, Jan 14, 2010 at 2:14 AM, Adrian Wiesmann awiesm...@somap.org wrote: Hi Alex i think we will not find one person who develops wicket-security allone - so who's interested? its not the part brings the most fun in wicket development area but a very very important part of every enterprise application - so contribute! lets define a security-subteam. I started with the built in security functionality and then moved to Apache Shiro. Shiro makes it very simple to authenticate users and to check permission from within your application code. And what I really like is that users of our tool still can personalise parts of those mechanisms when configuring their installation. Another plus is the permission based authorisation mechanism which makes defining and configuring permissions very flexible. So what I could contribute are classes to integrate Shiro into Wicket. If that is of interest. Cheers, Adrian - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: intercept security check in wicket-auth-roles
JSecurity has been renamed to Apache Shiro and is referenced in the linked page as 'wicket-shiro'. Cheers, Les On Mon, Jul 13, 2009 at 3:41 AM, Erik van Oosten e.vanoos...@grons.nlwrote: You don't have to use the spring xml config files to use Sprint Security. Just instantiate the beans from code! There is a small catch, you'll need to know something about Spring callbacks. These are some interface that Spring will automatically call. These are: InitializingBean, BeanNameAware, BeanFactoryAware and ApplicationContextAware. Hopefully Spring Security does not depend on them. But there are other options like jsecurity and lots of options on http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki. Regards, Erik. Brill Pappin wrote: Thanks for the heads up. I'll have to look at the security project again, but one thing I really like about auth-roles is that is so amazingly simply to deploy... however, I don't use spring (I'm a detractors of frameworks that use metadata where code should be) so I don't think its going to be any use to me here. - Brill On 11-Jul-09, at 3:47 AM, Olger Warnier wrote: The wicket-security framework has possibilities to integrate with SSO mechanisms. Next to that, you can integrate with spring-security and all authentication mechanisms supported by that. The yahoo-bbauth sample may help you to get an idea on how that works. Olger On 11 jul 2009, at 08:09, Brill Pappin wrote: I actually find it very usable and i love how simple it is... does the new security framework have a similar simple method of securing a site like that? - Brill On 3-Jul-09, at 11:34 AM, Igor Vaynberg wrote: wicket auth roles is an example, not a reusable framework. you should copy and paste the code into your project and customize as needed. -igor On Fri, Feb 20, 2009 at 8:30 AM, Brill Pappinbr...@pappin.ca wrote: I'm trying to integrate wicket-auth-roles with a token based SSO security system. I can't see where I can intercept the authentication sequence and auto-login the user based on the token. Essentially i want to catch the authentication request and authorize the user based on a token before they are redirected to the login page. Does anyone have a clue how I might go about doing that? Unfortunately most places I've looked to over ride the sequence are marked final for some reason, which makes things difficult. I'm actually at the point now where I'm thinking of writing a new auth-roles based on the current lib, but I thought I'd ask first. ... and no, I don't want to use the other more complex security lib... auth-roles is very nice and simple to use and suitable for most applications. - Brill Pappin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicketstuff / ki / jsecurity
Yep, I agree - please feel free to contribute. We might want to hold off on the name change though. There *might* be a name discrepancy with ki and another project in the interwebs. We're still waiting on what we should do per the project Mentors after they come back from Apache Con, where they're currently discussing the situation with other ASF members. Regards, Les On Wed, Mar 25, 2009 at 4:12 AM, Maarten Bosteels mbosteels@gmail.comwrote: Hi Ryan, I added you to the Project Members, so feel free to commit your examples. Unfortunately, until now I haven't had time to work on it myself The idea was to let the code mature in http://code.google.com/p/wicket-jsecurity/ and maybe move it to wicket-stuff later on. Maybe we should move it to wicket-stuff already. My main problem with wicket-stuff is/was that it's not always very clear which projects are still alive and maintained and which are practically dead. And at the time, wicket-stuff had some problems with continuous integration, IIRC. Les, what do you think ? We should change the project name to wicket-ki anyway. regards, Maarten On Wed, Mar 25, 2009 at 7:47 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: Yeah I've for one always been very pro for wicketstuff.. It's nice keeping things in one place.. Plus as you write if we share a somewhat similar structure it's potentially easier to maintain.. 2009/3/24 Ryan McKinley ryan...@gmail.com Hi- I've been looking to integrate a complex security model with wicket -- jsecurity seems really good. I tried messing with: http://code.google.com/p/wicket-jsecurity/ This appears to be a starting place, but does not have any running example. In an effort to get things running (and learn JSecurity) i took that + wicket-auth-roles and tried to make a functioning core + example. I've got something running and would love to share it... Should I post this to the google code site? It makes more sense (to me) if we keep it in the wicketstuff repos -- that way we get the benefit of Jeremy's work to make wickettuff-core much cleaner. Thoughts? Ryan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Security in a Spring Wicket layered application
Hi Kent, Although it is early, I am using the wicket-jsecurity integration in one of my (big) projects. It is working pretty well. Feel free to ask questions - I'm happy to help along the way. Cheers, Les (JSecurity founder) On Tue, Mar 10, 2009 at 1:42 PM, Kent Larsson kent.lars...@gmail.comwrote: 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 ryan...@gmail.com 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 kent.lars...@gmail.com 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 e.vanoos...@grons.nl 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To
Re: Wicket Security Question
Yep, I've been playing around with integration and will use it in a production deployment soon. So far, so good. I'm open to any feedback. I'm particularly happy with the PageStore implementation to use JSecurity's enterprise session management in a distributed environment - I needed to write it to support the case where Session objects did not reside in the same JVM where Wicket was executing. I would also think JSecurity would be a better fit for Wicket as a whole since it does not require Spring. It integrates beautifully with Spring if desired, it is just not a requirement... Cheers, Les On Fri, Feb 27, 2009 at 4:36 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: Ahh ok, Just wrote Les... 2009/2/27 Maarten Bosteels mbosteels@gmail.com I created a google-code project for Wicket-JSecurity integration, but unfortunately haven't had time to work on it. Les has already done some commits though. http://code.google.com/p/wicket-jsecurity/ Any help is welcome. regards, Maarten On Fri, Feb 27, 2009 at 8:31 AM, Wayne Pope waynemailingli...@googlemail.com wrote: Hi, In terms of SWARM etc its in the pre-generics stage. It didn't take much to get it working with the latest wicket version mind. It works fine, however it wan't what we needed in the end - we went with the wicket.aurthorization package and rolled our own dynamic acl-list/roles etc. I had some promising converstions with Les Hazlewood from jsecurity.org - that looks like another great package and more flexible IMO. However Les was right in the middle of a move to NYC and didn't have anytime to spend on doing a wicket version of jsecurity. It might be worth pinging him a mail and see if he up for doing it again. Wayne www.glasscubes.com On Thu, Feb 26, 2009 at 8:09 PM, Nino Martinez nino.martinez.w...@gmail.com wrote: I might pick it up (But since it's not something I need right now, it has low priority).. But was hoping that Wayne Pope would get back and tell whats state it is in.. Philippe Laflamme wrote: FYI: it's not clear what will happen with the wicket-security package. The original maintainer sadly passed away last year and no-one has officially taken the torch. We've used both packages (auth-roles and swarm), but neither with spring-security. We'd like to move to using spring-security using Swarm, but we haven't taken any step in this regard due to the package's situation... Hoping the package gets an official maintainer soon. Philippe Markus Strickler wrote: Hi- http://wicketstuff.org/confluence/display/STUFFWIKI/Security+Framework+Comparison might be of interest. I've been using Auth-roles together with ACEGI in a project and it worked quite well. -markus Am 25.02.2009 um 21:23 schrieb M Goodell: I would like to pose a question. We are looking at using Wicket as a platform for an upcoming project. So far we are *really* liking what Wicket brings to the table. In terms of security / securing a web application our first thought was Spring Security. My question: Does Spring Security play nice with Wicket and is it a viable addition to a Wicket Application? Or, what are other alternatives are available for use to investigate. Thank you in advance for any thoughts, comments and suggestions. M. Goodell -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form submission - Javascript alert dialog
This is much easier than all the stuff I've been reading about ;)
I'll give it a try. Thanks!
Best,
Les
On Mon, Jan 5, 2009 at 11:01 AM, Steve Swinsburg
s.swinsb...@lancaster.ac.uk wrote:
If you use an AjaxButton you can use the AjaxRequestTarget like so:
AjaxButton submitButton = new AjaxButton(submit) {
protected void onSubmit(AjaxRequestTarget target, Form form) {
if(save(form)) {
//successful
} else {
String js = alert('Failed');;
target.appendJavascript(js);
}
}
};
A custom save() method processes the form and returns true or false. Could
also do it in the onSubmit method if you prefer. So long as you return some
sort of status, then do the appendJavascript()
cheers,
Steve
On 5 Jan 2009, at 15:50, Les Hazlewood wrote:
I should clarify, just in case, that the alert/popup I'm talking about is
shown AFTER an unsuccessful submission, NOT before the form is allowed to
submit (a common case, such as using javascript form validation - that's
not
what I'm looking for :) ).
On Mon, Jan 5, 2009 at 10:49 AM, Les Hazlewood l...@hazlewood.com wrote:
Hi all,
I have a quick question that I hope is easily answered by some of the
Wicket gurus on this list :)
I have a simple requirement to show a popup dialog if form submission
fails. Think of it as the feedback panel that usually shows error
messages,
but in a popup instead of embedded into the page.
I've been digging in the depths of Wicket Javascript support (wiki, mailing
list searches, etc) to see if I can show a dead simple javascript alert
dialog instead of the feedback panel, but I'm having a hard time actually
finding a concrete area where I should focus my efforts or how to show that
alert in the event of a failure only.
Can anyone tell me how this is done or point to me to where I might be able
to read to make this happen?
The popup can be a simple alert dialog for starters, but should probably
evolve to some sexy CSS z-indexed panel later on. This is ultimately due
to
supporting a very small login form in the home page. Any error messages
wouldn't fit in or near that login form - or they'd just make that
particular div (and the page around it) look really ugly if the feedback
were embedded in the html.
Any help or guidance to resources is much appreciated!
Thanks,
Les
Form submission - Javascript alert dialog
Hi all, I have a quick question that I hope is easily answered by some of the Wicket gurus on this list :) I have a simple requirement to show a popup dialog if form submission fails. Think of it as the feedback panel that usually shows error messages, but in a popup instead of embedded into the page. I've been digging in the depths of Wicket Javascript support (wiki, mailing list searches, etc) to see if I can show a dead simple javascript alert dialog instead of the feedback panel, but I'm having a hard time actually finding a concrete area where I should focus my efforts or how to show that alert in the event of a failure only. Can anyone tell me how this is done or point to me to where I might be able to read to make this happen? The popup can be a simple alert dialog for starters, but should probably evolve to some sexy CSS z-indexed panel later on. This is ultimately due to supporting a very small login form in the home page. Any error messages wouldn't fit in or near that login form - or they'd just make that particular div (and the page around it) look really ugly if the feedback were embedded in the html. Any help or guidance to resources is much appreciated! Thanks, Les
Re: Form submission - Javascript alert dialog
I should clarify, just in case, that the alert/popup I'm talking about is shown AFTER an unsuccessful submission, NOT before the form is allowed to submit (a common case, such as using javascript form validation - that's not what I'm looking for :) ). On Mon, Jan 5, 2009 at 10:49 AM, Les Hazlewood l...@hazlewood.com wrote: Hi all, I have a quick question that I hope is easily answered by some of the Wicket gurus on this list :) I have a simple requirement to show a popup dialog if form submission fails. Think of it as the feedback panel that usually shows error messages, but in a popup instead of embedded into the page. I've been digging in the depths of Wicket Javascript support (wiki, mailing list searches, etc) to see if I can show a dead simple javascript alert dialog instead of the feedback panel, but I'm having a hard time actually finding a concrete area where I should focus my efforts or how to show that alert in the event of a failure only. Can anyone tell me how this is done or point to me to where I might be able to read to make this happen? The popup can be a simple alert dialog for starters, but should probably evolve to some sexy CSS z-indexed panel later on. This is ultimately due to supporting a very small login form in the home page. Any error messages wouldn't fit in or near that login form - or they'd just make that particular div (and the page around it) look really ugly if the feedback were embedded in the html. Any help or guidance to resources is much appreciated! Thanks, Les
Re: Wicket Security - best practices?
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
Re: Wicket Security - best practices?
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
Re: Wicket Security - best practices?
Haha, funny you should ask this - I'm doing it now ;) 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. Any questions that I could help with in particular in the meantime? 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]
