Roller's use of j_security_check for logins

[Allen Gilliland <al...@sun.com>]

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

Re: Roller's use of j_security_check for logins

[Elias Torres <el...@torrez.us>]

+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
> 

Re: Roller's use of j_security_check for logins

[Allen Gilliland <al...@sun.com>]

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" 
> <al...@sun.com>
> To: <ro...@incubator.apache.org>
> 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 <al...@sun.com> 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
>>>>
>>>
>>>
>>
> 

Re: Roller's use of j_security_check for logins

[Anil Gangolli <an...@busybuddha.org>]

Haven't heard of this issue in other settings either, but am ok with the 
change.

--a.

----- Original Message ----- 
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
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 <al...@sun.com> 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
>>>
>>
>>
> 

Re: Roller's use of j_security_check for logins

[Allen Gilliland <al...@sun.com>]

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 <al...@sun.com> 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
>>
> 
> 

Re: Roller's use of j_security_check for logins

[Matt Raible <mr...@gmail.com>]

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.

Matt

On 2/15/07, Allen Gilliland <al...@sun.com> 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
>


-- 
http://raibledesigns.com