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
