Hi Aaron,

See my comments in-line

On Mon, 2005-02-07 at 10:49 -0500, Aaron Hamid wrote:
> Hi folks, sorry for the cross posting but I think this issue is relevant 
> to both projects.
> 

<snip>

> There are two problems I have found, one in http client, one in Slide.  
> First, it seems that CredentialsProvider ONLY is called upon a challenge 
> from the server (HttpMethodDirector, 'promptForCredentials'), and never 
> pre-emptively, even if I setAuthenticationPreemptive(true).  My 
> expectation would be that if I set preemptive authentication than my 
> registered CredentialsProvider should be called prior to the request 
> being made.  Our custom auth doesn't use an HTTP challenge, so the creds 
> are required to be there to begin with.

I can explain this. The problem is that only Basic authentication can be
used preemptively and required by HTTP spec for compatibility reasons.
All other schemes either cannot be used preemptively (NTLM) or should
not be used preemptively (Digest to some extent).

Firstly, challenge-less authentication schemes are inherently insecure,
because they allow the authentication credentials to be sent to an
unknown party. Even if the credentials are encrypted using a predefined
encryption algorithm, one can still easily pull off a 'man in the
middle' type of exploit.

Secondly, the so called 'expect: continue' handshake renders the
preemptive authentication virtually superfluous. For a fairly small
price one gains a lot in terms of security.

Bottom line, if your web server supports HTTP/1.1, which is a
commonplace these days, disable the preemptive authentication, enable
the 'expect: continue' handshake and live happily ever after.

> 
> In addition, it seems that the HTTP Method implementations of Slide use 
> a default AuthState (in HttpMethodBase).  Apparently it uses BASIC auth 
> as the default scheme, and does not pick up the global defaults (I tried 
> registering my parameters on the DefaultParams* singleton after 
> discovering this, to see if they would be picked up, but they are not).
> 

I do not know much about Slide's inner working, but I'll be willing to
take a look at the Slide source code, should this be required.


> I think the first quick fix is to update HttpMethodDirector so it uses 
> CredentialsProvider preemptively (if one is defined, and 
> setAuthenticationPreemptive is set).
> 

See above.

> I'm not sure how to handle the second problem because I am not 
> thoroughly familiar with the design decisions and abstractions behind 
> HttpClient and expected usage.  I would think either the Slide 
> WebdavResource should expose the HttpClient with the real AuthState it 
> will use (I know I can get HttpClient through 
> WebdavSession.getSessionInstance... but it appears the default AuthState 
> in the Method "overrides" anything I set), or have the default authstate 
> inherit global defaults (perhaps lazily).
> 

See above.

Cheers,

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to