Matt,

i think all the new files that are needed are missing.  like the 
WEB-INF/security.xml and the new jars, etc.

maybe you can package that stuff up in a zip file and add that to the wiki as 
well?

-- Allen


On Wed, 2005-09-28 at 11:26, Matt Raible wrote:
> It's attached to the proposal.
> 
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_AcegiSecurity
> 
> Please note the remaining issues listed on the wiki.
> 
> Matt
> 
> On 9/28/05, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> > 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
> > > >
> > > >
> >
> >

Reply via email to