Matt, I wasn't able to recieve the patch you sent with this email probably because it got caught by a spam filter or something.
can you possibly post it somewhere on the web so I can grab it? -- Allen On Mon, 2005-09-19 at 16:36, Matt Raible wrote: > On 9/17/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > 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? > > No, I should do this. First, I wanted to prove that it would actually > work. As far as SSO, Acegi integrates with Yale's CAS system - more > information is available in Acegi's documentation. > > http://acegisecurity.sourceforge.net/docbook/acegi.html#security-cas > > If you look at the forum link below, you'll see I got an answer to my > question and was able to get everything working today. I've attached > a patch of what changes in existing classes. > > The biggest change is that a lot of the startup logic in LoginServlet > moved to RollerContext (where everything else is initialized). Other > changes include removing the secure and unsecure port numbers in > roller.properties. This is because Acegi defaults to 8443 (when using > 8080 for http://) and 443 (when using 80 for http://). > > The one thing I haven't done in this patch is to remove the UserCookie > object (and code from UserManager) - but this will no longer be > necessary either. > > I'll try to write up a proposal on the wiki in the next day or two. > Any suggestions on an existing proposal to use for a template? > > Thanks, > > Matt > > > > > > -- 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 > > > >
