You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2008/07/29 17:09:18 UTC
A strange authcBasic behaviour
Hi there,
i just discovered a bug?
When a HTTP Request comes in to resource (url) protected with
authcBasic, BUT the header looks like this (sorry for formatting,
copied from firebug):
Host: localhost:8081
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Accept: application/json
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Authorization: NexusAuthToken DEPRECATED
Referer: http://localhost:8081/nexus/
Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
The authcBasis stops the chain (protects it all right) but responds
with HTTP 200....
Corresponding log snippet:
INFO] 2008-07-29 17:05:51,925 DEBUG
[org.jsecurity.web.attr.CookieAttribute] - No value found in request
Cookies under cookie name [rememberMe]
[INFO] 2008-07-29 17:05:51,927 DEBUG
[org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
Attempting to authenticate Subject based on Http BASIC Authentication
request...
[INFO] 2008-07-29 17:05:51,927 DEBUG
[org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
Executing login with headers [NexusAuthToken DEPRECATED]
[INFO] 2008-07-29 17:05:51,927 DEBUG
[org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
Returning [false] from executeLogin()
[INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
/nexus/service/local/authentication/login 200
As you see, the Authorization is NOT Basic, it is some custom scheme.
Should not authcBasic in this case simply resendChallenge?
The response is obviously wrong, this should not be HTTP 200.
--
Thanks,
~t~
Re: A strange authcBasic behaviour
Posted by Les Hazlewood <le...@hazlewood.com>.
Hi Tamás,
I just looked at the source code, and it appears a 200 response might be
returned in some cases.
I've just committed a change that will always send back a challenge in all
cases except when 1) the user is already authenticated and 2) if they're not
authenticated yet but they've successfully authenticated during the current
request. This should be the case ;)
Cheers,
Les
On Tue, Jul 29, 2008 at 11:31 AM, Allan Ditzel <al...@gmail.com>wrote:
> Hi Tamas,
>
> I'll take a look at it as soon as I'm able to get some free time today!
>
> Thanks!
>
> Allan
>
> On Tue, Jul 29, 2008 at 11:09 AM, Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > Hi there,
> >
> > i just discovered a bug?
> >
> > When a HTTP Request comes in to resource (url) protected with
> > authcBasic, BUT the header looks like this (sorry for formatting,
> > copied from firebug):
> >
> > Host: localhost:8081
> > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> > rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
> > Accept: application/json
> > Accept-Language: en-us,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > X-Requested-With: XMLHttpRequest
> > Authorization: NexusAuthToken DEPRECATED
> > Referer: http://localhost:8081/nexus/
> > Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
> >
> > The authcBasis stops the chain (protects it all right) but responds
> > with HTTP 200....
> >
> > Corresponding log snippet:
> > INFO] 2008-07-29 17:05:51,925 DEBUG
> > [org.jsecurity.web.attr.CookieAttribute] - No value found in request
> > Cookies under cookie name [rememberMe]
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Attempting to authenticate Subject based on Http BASIC Authentication
> > request...
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Executing login with headers [NexusAuthToken DEPRECATED]
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Returning [false] from executeLogin()
> > [INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
> > /nexus/service/local/authentication/login 200
> >
> > As you see, the Authorization is NOT Basic, it is some custom scheme.
> > Should not authcBasic in this case simply resendChallenge?
> >
> > The response is obviously wrong, this should not be HTTP 200.
> >
> > --
> > Thanks,
> > ~t~
> >
>
Re: A strange authcBasic behaviour
Posted by Allan Ditzel <al...@gmail.com>.
Hi Tamas,
I'll take a look at it as soon as I'm able to get some free time today!
Thanks!
Allan
On Tue, Jul 29, 2008 at 11:09 AM, Tamás Cservenák <ta...@cservenak.net>
wrote:
> Hi there,
>
> i just discovered a bug?
>
> When a HTTP Request comes in to resource (url) protected with
> authcBasic, BUT the header looks like this (sorry for formatting,
> copied from firebug):
>
> Host: localhost:8081
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
> Accept: application/json
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> X-Requested-With: XMLHttpRequest
> Authorization: NexusAuthToken DEPRECATED
> Referer: http://localhost:8081/nexus/
> Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
>
> The authcBasis stops the chain (protects it all right) but responds
> with HTTP 200....
>
> Corresponding log snippet:
> INFO] 2008-07-29 17:05:51,925 DEBUG
> [org.jsecurity.web.attr.CookieAttribute] - No value found in request
> Cookies under cookie name [rememberMe]
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Attempting to authenticate Subject based on Http BASIC Authentication
> request...
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Executing login with headers [NexusAuthToken DEPRECATED]
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Returning [false] from executeLogin()
> [INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
> /nexus/service/local/authentication/login 200
>
> As you see, the Authorization is NOT Basic, it is some custom scheme.
> Should not authcBasic in this case simply resendChallenge?
>
> The response is obviously wrong, this should not be HTTP 200.
>
> --
> Thanks,
> ~t~
>
Re: A strange authcBasic behaviour
Posted by Les Hazlewood <le...@hazlewood.com>.
Hi Tamas - I just checked in your suggestions. Please try it out!
On Tue, Jul 29, 2008 at 4:10 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> Yeah, I was thinking about this - specifically how to also cleanly support
> HTTP Digest authentication as well.
>
> I'll make the changes you recommend - they're good practice. I'll ping
> this list again when the change is in.
>
> Thanks!
>
> Les
>
>
> On Tue, Jul 29, 2008 at 3:22 PM, Tamás Cservenák <ta...@cservenak.net>wrote:
>
>> Hi there,
>>
>> i see this issue is tackled in svn trunk... but it will not help the
>> users to support "custom" authentication schemes...
>>
>> Would not be "more exact" if you do the following?
>>
>> protected boolean isLoginAttempt( ServletRequest request,
>> ServletResponse response )
>> {
>> HttpServletRequest httpRequest = toHttp( request );
>>
>> String authorizationHeader = httpRequest.getHeader(
>> AUTHORIZATION_HEADER );
>>
>> return authorizationHeader != null &&
>> authorizationHeader.toLowerCase().startsWith( "basic" );
>> }
>>
>> Since the BasicHttpAuthenticationFilter does HTTP BASIC auth only (out
>> of the box), it should check for auth scheme also.... otherwise, if
>> not BASIC, it should simply take it as non-login-attempt request.
>>
>> And if someone implements "custom" scheme, he should only override the
>> isLoginAttemp() and executeLogin() methods to implement it's custom
>> auth scheme...
>>
>> ~t~
>>
>>
>> On Tue, Jul 29, 2008 at 5:09 PM, Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>> > Hi there,
>> >
>> > i just discovered a bug?
>> >
>> > When a HTTP Request comes in to resource (url) protected with
>> > authcBasic, BUT the header looks like this (sorry for formatting,
>> > copied from firebug):
>> >
>> > Host: localhost:8081
>> > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
>> > rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
>> > Accept: application/json
>> > Accept-Language: en-us,en;q=0.5
>> > Accept-Encoding: gzip,deflate
>> > Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> > Keep-Alive: 300
>> > Connection: keep-alive
>> > X-Requested-With: XMLHttpRequest
>> > Authorization: NexusAuthToken DEPRECATED
>> > Referer: http://localhost:8081/nexus/
>> > Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
>> >
>> > The authcBasis stops the chain (protects it all right) but responds
>> > with HTTP 200....
>> >
>> > Corresponding log snippet:
>> > INFO] 2008-07-29 17:05:51,925 DEBUG
>> > [org.jsecurity.web.attr.CookieAttribute] - No value found in request
>> > Cookies under cookie name [rememberMe]
>> > [INFO] 2008-07-29 17:05:51,927 DEBUG
>> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
>> > Attempting to authenticate Subject based on Http BASIC Authentication
>> > request...
>> > [INFO] 2008-07-29 17:05:51,927 DEBUG
>> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
>> > Executing login with headers [NexusAuthToken DEPRECATED]
>> > [INFO] 2008-07-29 17:05:51,927 DEBUG
>> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
>> > Returning [false] from executeLogin()
>> > [INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
>> > /nexus/service/local/authentication/login 200
>> >
>> > As you see, the Authorization is NOT Basic, it is some custom scheme.
>> > Should not authcBasic in this case simply resendChallenge?
>> >
>> > The response is obviously wrong, this should not be HTTP 200.
>> >
>> > --
>> > Thanks,
>> > ~t~
>> >
>>
>>
>>
>> --
>> Thanks,
>> ~t~
>>
>
>
Re: A strange authcBasic behaviour
Posted by Les Hazlewood <le...@hazlewood.com>.
Yeah, I was thinking about this - specifically how to also cleanly support
HTTP Digest authentication as well.
I'll make the changes you recommend - they're good practice. I'll ping this
list again when the change is in.
Thanks!
Les
On Tue, Jul 29, 2008 at 3:22 PM, Tamás Cservenák <ta...@cservenak.net>wrote:
> Hi there,
>
> i see this issue is tackled in svn trunk... but it will not help the
> users to support "custom" authentication schemes...
>
> Would not be "more exact" if you do the following?
>
> protected boolean isLoginAttempt( ServletRequest request,
> ServletResponse response )
> {
> HttpServletRequest httpRequest = toHttp( request );
>
> String authorizationHeader = httpRequest.getHeader(
> AUTHORIZATION_HEADER );
>
> return authorizationHeader != null &&
> authorizationHeader.toLowerCase().startsWith( "basic" );
> }
>
> Since the BasicHttpAuthenticationFilter does HTTP BASIC auth only (out
> of the box), it should check for auth scheme also.... otherwise, if
> not BASIC, it should simply take it as non-login-attempt request.
>
> And if someone implements "custom" scheme, he should only override the
> isLoginAttemp() and executeLogin() methods to implement it's custom
> auth scheme...
>
> ~t~
>
>
> On Tue, Jul 29, 2008 at 5:09 PM, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> > Hi there,
> >
> > i just discovered a bug?
> >
> > When a HTTP Request comes in to resource (url) protected with
> > authcBasic, BUT the header looks like this (sorry for formatting,
> > copied from firebug):
> >
> > Host: localhost:8081
> > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> > rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
> > Accept: application/json
> > Accept-Language: en-us,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > X-Requested-With: XMLHttpRequest
> > Authorization: NexusAuthToken DEPRECATED
> > Referer: http://localhost:8081/nexus/
> > Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
> >
> > The authcBasis stops the chain (protects it all right) but responds
> > with HTTP 200....
> >
> > Corresponding log snippet:
> > INFO] 2008-07-29 17:05:51,925 DEBUG
> > [org.jsecurity.web.attr.CookieAttribute] - No value found in request
> > Cookies under cookie name [rememberMe]
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Attempting to authenticate Subject based on Http BASIC Authentication
> > request...
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Executing login with headers [NexusAuthToken DEPRECATED]
> > [INFO] 2008-07-29 17:05:51,927 DEBUG
> > [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> > Returning [false] from executeLogin()
> > [INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
> > /nexus/service/local/authentication/login 200
> >
> > As you see, the Authorization is NOT Basic, it is some custom scheme.
> > Should not authcBasic in this case simply resendChallenge?
> >
> > The response is obviously wrong, this should not be HTTP 200.
> >
> > --
> > Thanks,
> > ~t~
> >
>
>
>
> --
> Thanks,
> ~t~
>
Re: A strange authcBasic behaviour
Posted by Tamás Cservenák <ta...@cservenak.net>.
Hi there,
i see this issue is tackled in svn trunk... but it will not help the
users to support "custom" authentication schemes...
Would not be "more exact" if you do the following?
protected boolean isLoginAttempt( ServletRequest request,
ServletResponse response )
{
HttpServletRequest httpRequest = toHttp( request );
String authorizationHeader = httpRequest.getHeader(
AUTHORIZATION_HEADER );
return authorizationHeader != null &&
authorizationHeader.toLowerCase().startsWith( "basic" );
}
Since the BasicHttpAuthenticationFilter does HTTP BASIC auth only (out
of the box), it should check for auth scheme also.... otherwise, if
not BASIC, it should simply take it as non-login-attempt request.
And if someone implements "custom" scheme, he should only override the
isLoginAttemp() and executeLogin() methods to implement it's custom
auth scheme...
~t~
On Tue, Jul 29, 2008 at 5:09 PM, Tamás Cservenák <ta...@cservenak.net> wrote:
> Hi there,
>
> i just discovered a bug?
>
> When a HTTP Request comes in to resource (url) protected with
> authcBasic, BUT the header looks like this (sorry for formatting,
> copied from firebug):
>
> Host: localhost:8081
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
> Accept: application/json
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> X-Requested-With: XMLHttpRequest
> Authorization: NexusAuthToken DEPRECATED
> Referer: http://localhost:8081/nexus/
> Cookie st-authToken=s%3ADEPRECATED; st-username=s%3Aadmin
>
> The authcBasis stops the chain (protects it all right) but responds
> with HTTP 200....
>
> Corresponding log snippet:
> INFO] 2008-07-29 17:05:51,925 DEBUG
> [org.jsecurity.web.attr.CookieAttribute] - No value found in request
> Cookies under cookie name [rememberMe]
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Attempting to authenticate Subject based on Http BASIC Authentication
> request...
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Executing login with headers [NexusAuthToken DEPRECATED]
> [INFO] 2008-07-29 17:05:51,927 DEBUG
> [org.jsecurity.web.filter.authc.BasicHttpAuthenticationFilter] -
> Returning [false] from executeLogin()
> [INFO] 2008-07-29 17:05:51,927 DEBUG [org.mortbay.log] - RESPONSE
> /nexus/service/local/authentication/login 200
>
> As you see, the Authorization is NOT Basic, it is some custom scheme.
> Should not authcBasic in this case simply resendChallenge?
>
> The response is obviously wrong, this should not be HTTP 200.
>
> --
> Thanks,
> ~t~
>
--
Thanks,
~t~