curl-library
Re: How-To use NTLM proxy authentication?
Date: Thu, 24 Mar 2005 12:22:42 -0800
Hmm, I'm looking at Curl_http_output_auth and I can see what's
happening, and I'm not sure how it ever worked. Basically,
Curl_http_auth_act seems to work fine. authproxy->picked gets set to
the right value. But for some reason, Curl_http_output_auth is looking
at authproxy->want instead of authproxy->picked. Should all the
if-elses compare against authproxy->picked instead, or is
authproxy->want supposed to get set to authproxy->picked at some point?
I can hack it to make it work, but I want it to be "right." Thoughts?
Augustus
PS Generating a spurious GET let's the NTLM handshake work, and then you
can POST successfully afterwards.
Augustus Saunders wrote:
>
> Ok, I've figured out basically what's happening. If you are POSTing
> form data, them libcurl does not complete the NTLM handshake. It
> sends the first "Proxy-Authentication: NTLM data" header, the proxy
> responds with "Access Denied" and provides the next step in the NTLM
> handshake, but the final "Proxy-Authentication: NTLM data" response
> from curl still has the original data--it doesn't finish the
> handshake. And so it goes into an infinite loop posting the same auth
> code over and over. If you use HTTP GET, it's all fine. I'm going to
> try issuing a spurious GET just to let the authentication work, and
> see if I can follow it up with POSTs. I'm getting lost tracking
> through the libcurl code figuring out why POST is different than GET
> in this respect.
>
> Also, I intend to figure out why CURLAUTH_ANY doesn't seem to work; I
> found the place in the code where that get's checked. Thanks-
>
> Augustus
>
> Augustus Saunders wrote:
>
>> Ok, I've got a little bit more information now. I've
>> actually got a MS ISA server set up now to test against. I
>> am using 7.13.1 and am having two problems:
>>
>> 1) When using "CURLAUTH_ANY" value for CURLOPT_PROXYAUTH, no
>> proxy-authorization headers are generated in the output.
>> 2) When I manually set the proxy authorization to be NTLM,
>> then it generates what appears to be an OK
>> "proxy-authorization: NTLM blahblah" header in the output,
>> but the proxy server responds with "Authorization denied."
>> Apparently, this sends libcurl into some infinite loop, as
>> it tries to send it over and over again (without ever
>> returning from curl_easy_perform).
>> I checked the curl executable I have under Cygwin, which is
>> 7.11.1, and it seemed to negotatiate the NTLM correctly when
>> given the --proxy-ntlm option (I wasn't sure how to tell the
>> command line program to guess which auth mode to use).
>>
>> Problem #1 is most likely user error on my part, although
>> your emails indicate that I'm doing the right steps. The
>> Authorization Denied thing is probably an OpenSSL problem,
>> right? The infinite loop thing is probably a bug ;)
>>
>> I built with OpenSSL 0.9.7e, and I did use the ASM build. I
>> noticed that they *just* released 7f, maybe I should try it?
>>
>> Any thoughts on how to further track this down would be most
>> appreciated. Thanks in advance-
>>
>> Augustus
>>
>> PS I was curious about the removal of the password callback
>> and looked at the email. Not sure I follow the reasoning
>> (that's ok, no need to explain again), but it looked like
>> technical reasons. I appologize for not following up on my
>> Sept 2002 offer for a patch to make a proxy-auth callback,
>> but hopefully anybody that reimplements the callback will
>> take care of proxy's while they're at it.
>>
>> On Tue, 22 Mar 2005 10:09:46 +0100 (CET)
>> Daniel Stenberg <daniel-curl_at_haxx.se> wrote:
>>
>>
>>> On Mon, 21 Mar 2005, Augustus Saunders wrote:
>>>
>>>
>>>
>>>> Thanks for the reply. Overall, it sounds like things
>>>>
>>>
>>> should "just work."
>>>
>>>> I'm going to try and get better outgoing header
>>>>
>>>
>>> captures using the
>>>
>>>> CURL_DEBUG options to try and figure out why it's not.
>>>>
>>>
>>> You should also make sure you use a recent libcurl
>>> version since we've been fixing bugs in this area recently.
>>>
>>>
>>>
>>>> 1) If proxy, set proxy settings
>>>> 2) Attempt POST
>>>> 3) while 407, ask for user name/password
>>>> 3a) POST again
>>>>
>>>
>>> Yes, if you don't have the name/password already I guess
>>> this is how you should do it.
>>>
>>>
>>>
>>>>>> Do I need to set up any of the SSL options?
>>>>>>
>>>>>
>>>>> No.
>>>>>
>>>>
>>>> What about for curl_global_init? Do I need to
>>>>
>>>
>>> initialize SSL?
>>>
>>> No, you don't. NTLM doesn't really use SSL, it just uses
>>> some crypto functions (for DES and MD4) that are present in one the SSL
>>> libraries. You don't have to init anything to use them.
>>>
>>>
>>>
>>>>> This is necessary. We did in fact _remove_ a callback
>>>>>
>>>>
>>> for this some time
>>>
>>>>> ago...
>>>>>
>>>>
>>>> That's interesting. How come?
>>>>
>>>
>>> The reasoning was posted to this list in October 2003:
>>>
>>> http://curl.haxx.se/mail/lib-2003-10/0100.html
>>>
>>>
>>>
>>>>> The default behavior was set years ago and I've not
>>>>>
>>>>
>>> yet seen any good
>>>
>>>>> reason to break backwards compatibility in that
>>>>>
>>>>
>>> aspect. Very few apps
>>>
>>>>> actually need or use the default behaviour anyway.
>>>>>
>>>>
>>>> I don't understand. The default behavior *intentially*
>>>>
>>>
>>> generates errors?
>>>
>>> No. You need to widen your perspective. It doesn't
>>> generate errors by default on most platforms I know of (and curl the
>>> command line
>>> tool assumes and uses the default behaviour on quite a few
>>> platforms). I'm not
>>> even sure exactly why you get these errors. But then I don't do much
>>> libcurl on
>>> windows. Possibly it happens because you don't have a stdout?
>>>
>>>
>>>
>>>> And people wrote applications depending on the fact
>>>>
>>>
>>> that spurious errors get
>>>
>>>> generated sporadically?
>>>>
>>>
>>> People who use and depend on the default behavior don't
>>> get these errors.
>>>
>>>
>>>
>>>> I mean, why don't you just say in the docs
>>>>
>>>
>>> "CURLOPT_WRITEFUNCTION must be
>>>
>>>> set or you will get Error writing body errors."
>>>>
>>>
>>> Because it isn't true to a majority.
>>>
>>>
>>>
>>>> That sounds exciting. What's the timeline looking like
>>>>
>>>
>>> for 13.2?
>>>
>>> I'd say within a few weeks. I have a larger change
>>> pending, and I'd prefer to have 7.13.2 released before I commit this
>>> larger work...
>>>
>>> You can always get a recent snapshot or CVS version and
>>> try it out before release to see if it solves your problems...
>>>
>>> --
>>> Daniel Stenberg -- http://curl.haxx.se --
>>> http://daniel.haxx.se
>>> Commercial curl and libcurl Technical Support:
>>> http://haxx.se/curl.html
>>>
>>
>>
>>
>>
>>
>
Received on 2005-03-24