cool ... this sounds like a welcome improvement over CMA. i know we've talked about using Acegi on the list before, but is there a proposal plan that outlines genrally how Acegi integration works, what new classes would be created, and how SSO would tie in?
-- Allen On Sat, 2005-09-17 at 08:34, Matt Raible wrote: > FYI... > > I did some work yesterday to create a version of Roller that uses > Acegi Security for its security mechanism as an alternative to CMA. > It's my believe that this should be possible w/o changing a single > line of Java code. In fact, it should result in deleting quite a bit > of code (LoginServlet, LoginFilter, UserCookie, etc.). > > However, I've run into one issue. > > <snip> > Principal principal = request.getUserPrincipal(); > String username = principal.getName(); > > With CMA, this returns "mraible" (my login name). However, with Acegi, > it returns: > > userName= "[EMAIL PROTECTED]: Username: > mraible; Password: [PROTECTED]; Enabled: true; AccountNonExpired: > true; credentialsNonExpired: true; AccountNonLocked: true; Granted > Authorities: editor" > </snip> > > I've posted this to the Acegi Security forums, but haven't had a response > yet. > > http://forum.springframework.org/viewtopic.php?t=8917 > > I suspect it's a bug. A workaround is to use request.getRemoteUser(), > but I'd rather see this fixed in Acegi. > > To reiterate why I'm doing this little experiment: it's because Acegi > has more fine-grained control of security - allowing you to get a > user's role or information in any layer (b/c the information is stored > in a thread local). Furthermore, it has Remember Me and SSL Switching > built in. > > AppFuse had the same setup that Roller has at one point. In fact, most > of the Login/RememberMe/SSL Switching is from AppFuse. I switched to > Acegi in AppFuse about 6 months ago and it's resulted in nothing but > good things. We've been able to plug a few security holes that > would've been more difficult if we were using CMA. > > Another good reason to switch is this will get us away from something > users complain about often: the redirect to j_security_check - where > the password is shown in the URL. > > Have a good weekend, > > Matt
