A strange authcBasic behaviour

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

A strange authcBasic behaviour

Tamás Cservenák
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~
Reply | Threaded
Open this post in threaded view
|

Re: A strange authcBasic behaviour

Allan Ditzel
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 <[hidden email]>
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~
>
Reply | Threaded
Open this post in threaded view
|

Re: A strange authcBasic behaviour

Les Hazlewood
Administrator
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 <[hidden email]>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 <[hidden email]>
> 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~
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: A strange authcBasic behaviour

Tamás Cservenák
In reply to this post by Tamás Cservenák
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 <[hidden email]> 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~
Reply | Threaded
Open this post in threaded view
|

Re: A strange authcBasic behaviour

Les Hazlewood
Administrator
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 <[hidden email]>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 <[hidden email]>
> 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~
>
Reply | Threaded
Open this post in threaded view
|

Re: A strange authcBasic behaviour

Les Hazlewood
Administrator
Hi Tamas - I just checked in your suggestions.  Please try it out!

On Tue, Jul 29, 2008 at 4:10 PM, Les Hazlewood <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>> 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~
>>
>
>