+1
Allen Gilliland wrote: > guys, > > I've come across a bit of a quirk/bug in Roller based on the fact that > we have Acegi configured to take over the use of the /j_security_check > url for doing logins. > > It appears that the way the j_security_check url is handled varies > between the different containers and after doing some testing on some of > the Sun containers I've found that they enforce more strict rules on how > that url can be used which breaks our Acegi login process. Basically, > on some containers a form posting to /j_security_check will never make > it to the Acegi security filter because the container won't allow it. > > I have read through the servlet spec and asked some of the Sun Webserver > team for their input on the issue and the fact is that this is a kind of > gray area which is not explicitly detailed in the servlet spec. However, > the recommendation was that we should probably not be trying to use the > j_security_check for Acegi authentication because it can interfere with > the way that container-managed security is meant to work. > > The ramifications of this bug are that you can't deploy Roller to some > containers and have it work without having to hand modify a couple of > files within the webapp. To fix the issue is actually very simple, all > that is required is for us to change the Acegi authentication posting > url from /j_security_check to anything else, i.e. > /roller_j_security_check would work fine. As far as I can see there is > no real downside to doing this and no real reason why we need to use > /j_security_check as the url for Acegi authentication. > > So, I'd like to propose that we change this in Roller so that by default > Roller will avoid any possible collision conflicts with the way > containers handle the /j_security_check url. > > Thoughts? Anyone object to this change? > > -- Allen >
