Hi Tamas - I just checked in your suggestions. Please try it out!
On Tue, Jul 29, 2008 at 4:10 PM, Les Hazlewood <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>
>> 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~
>>
>
>
