I am sorry to bother you so much these days
(I just forgot to change the from-tag in my last posting).
>>the handling of failed authentification with NTLM is not yet satisfying.
>Can you tell me an example on how to get into trouble with the current
I can reproduce unexpected behaviour. But I don't know if this is
because of one or two problems.
Let's say there are two problems.
Then the first has nothing to do with NTLM as it is the same with BASIC.
I did not realize it until now as it does not happen in windows programs
(I broke my head, but can not undersand why).
On console application curl_easy_perform() does not return at all on
failing (proxy) authorization with empty password.
I set CURLOPT_PROXYUSERPWD to "username:".
I expect it to try the empty string (as the colon is not missing) and
return if this fails.
But different from normal passwords it starts calling the password
callback until authorizaiton passes.
This does neither happen with not empty passwords nor in windows
With NTLM I can easily reproduce the upper also with not empty passwords.
In windows applications it uses the same password again and again.
>>This happens i.e. if you set CURLOPT_PROXYUSERPWD to "" which is then
>>defaulted in CreateConnection() to CURL_DEFAULT_USER and
>>CURL_DEFAULT_PASSWORD (currently "anonymous:curl_by_daniel_at_haxx.se").
>Aren't you mixing matters now? They're set in the user+password fields if
>CURLOPT_USERPWD (note that this is not the CURLOPT_PROXYUSERPWD) option wasn't
Yes you are completely right. Sorry, mixed it up.
>>Should we rather try checking the scheme in the url before setting a
>We could. I don't think we ever use the default user+password when we talk
>HTTP, so copying that data is a pure waste in that case.
This was an aftereffect of the mixing up above. Forget what I wrote on this.
>>2. If you set CURLOPT_PROXYUSERPWD to NULL we will segfault in
>>Curl_output_ntlm() with ntlm->state NTLMSTATE_TYPE2 or later in mkhash(). (I
>>would be happier to add a NULL check before strlen() and toupper().) The
>>quickest implementation would be to return !=0 from Curl_output_ntlm() but
>>is this OK
>We could argue if setting CURLOPT_PROXYUSERPWD to NULL should still be trying
>to use any authentication method at all, so we could just return an error if
>this is the case. Can you figure out any sensible use case when NULL is
>expected to be set?
I see it the same way as you. NULL is the same as not setting the option
and should result in not trying to pass any authentification.
But it tries to pass the NTLM authentification and segfaults.
>(I'm currently working on re-arranging some source-code to better support the
>auth stuff for the proxy CONNECT loop.)
Oh! I am very happy to hear this.
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Received on 2003-09-01