I've gone ahead and committed this change to the trunk at revision 508659.
The change just replaces "j_security_check" with
"roller_j_security_check" in these 2 files ...
jsps/core/login.jsp
security.xml
-- Allen
Anil Gangolli wrote:
Haven't heard of this issue in other settings either, but am ok with the
change.
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, February 15, 2007 3:45 PM
Subject: Re: Roller's use of j_security_check for logins
Matt Raible wrote:
I'm fine with this change - I also haven't heard any issues from users
using this in AppFuse. But we probably haven't tested as many
containers as you have. Do you have a specify app server name and
version that this fails on? I'd like to try AppFuse and see if it
fails too.
Yeah, I know it doesn't work with Sun Webserver 7 ...
http://www.sun.com/download/products.xml?id=45ad781d
I does surprise me that nobody else has run into this issue yet, but
then again many of the other containers are much more lax on their
interpretations of the servlet spec. I was actually surprised to find
that I had been using an app on tomcat 5.5 which didn't even have a
resource-ref defined in the web.xml file for a jdbc resource and yet
tomcat never complained about it.
-- Allen
Matt
On 2/15/07, Allen Gilliland <[EMAIL PROTECTED]> 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
