gmane.comp.web.curl.general

RE: Digest authorized

Daniel Stenberg — 2008-12-01T14:20:26

No, that doesn't fix the problem. It is what looks to be a good way towards a fix, but we don't want it to be a compile-time option as most clients will want to be able to work against both good Digest servers and "bad" ones. It needs to be a new curl_easy_setopt() option. I don't fix binaries at all generally.

RE: Digest authorized

Левченко Кирилл Сергеевич — 2008-12-01T14:09:36

Resolve problem's. http://curl.haxx.se/mail/tracker-2007-09/0018.html Can you get fixed binary for debian? ------ So, I would claim that we really can't fix this "properly" but we need to add some kind of option for libcurl >that tells it to do Digest like IE did before version 7! :-( Can you think of any other way and if not, would you be able to work on a patch for this?

RE: Digest authorized

Daniel Stenberg — 2008-12-01T13:11:19

Ah now this rings a little bell in the back of my mind. Yuck. And out comes evilness: http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html#msie And the quote is: Since version 2.0.51 Apache also provides a workaround in the AuthDigestEnableQueryStringHack environment variable. If AuthDigestEnableQueryStringHack is set for the request, Apache will take steps to work around the MSIE bug and remove the query string from the digest comparison. Also found this page with some other findings on HTTP Digest differences: http://www.fngtps.com/2006/09/http-authentication So, I would claim that we really can't fix this "properly" but we need to add some kind of option for libcurl that tells it to do Digest like IE did before version 7! :-( Can you think of any other way and if not, would you be able to work on a patch for this?

RE: Digest authorized

Левченко Кирилл Сергеевич — 2008-12-01T13:07:19

Header IE: .... uri="/Main.aspx", .... Header curl: .... uri="/Main.aspx?Method=List" Wrong uri -> Wrong response. ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

RE: Digest authorized

Daniel Stenberg — 2008-12-01T08:28:34

Please don't top-post. Then please enlighten us how that information helps us to track down this problem?

RE: Digest authorized

Левченко Кирилл Сергеевич — 2008-12-01T05:00:37

Iexplorer can connect to xxx.ru Headers IE: From server: --- HTTP/1.1 401 Unauthorized Content-Length: 1656 Content-Type: text/html Server: Microsoft-IIS/6.0 WWW-Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="486735007c4fc901aaef97b9ecfe18ece23f8bd 5f86d8e18913df91e2b52cdaf8197ce924bc15122",charset=utf-8,realm="xxx.ru" X-Powered-By: ASP.NET Date: Wed, 26 Nov 2008 04:03:55 GMT ---- From IE: ---GET /Main.aspx?Method=List HTTP/1.1 Accept: */* Accept-Language: ru Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 1.1.4322) Host: 172.21.159.13 Connection: Keep-Alive Authorization: Digest username="user", realm="xxx.ru", qop="auth", algorithm="MD5-sess", uri="/Main.aspx", nonce="282bfb0b7c4fc90186f7305500b7b3ad5dd3cde30ebe9f3bf1774b08a14774fa9affb 2b615c6e9d1", nc=00000001, cnonce="ae3ecc694d860f76551b79d668f730d5", response="f9bc7ba46e1ea92f6af88f1be65d2216" --- -----Original Message----- From: curl-users-bounces< at >cool.haxx.se [mailto:curl-users-bounces< at >cool.haxx.se] Sent: Wednesday, November 26, 2008 6:39 PM To: the curl tool Subject: Re: Digest authorized On Wed, 26 Nov 2008, ???????? ?????? ????????? wrote: Can you provide us with a test account on a similar setup? It seems you're either suffering from a bug (in the server or in libcurl) or you're providing the wrong credentials to the server. We have a number of Digest tests in the test suite and they all work fine. We need to figure out how your case differs from them! ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Re: trying to simulate login to UPS (willing to $pay$ for solution)

Mike Protts — 2008-11-30T11:01:53

I think the problem may be session cookies, you may find that using a single curl session (init once and only close when finished) would be better. Cheers Mike ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Re: trying to simulate login to UPS (willing to $pay$ for solution)

Daniel Stenberg — 2008-11-30T09:50:02

That's a PHP script using the PHP/CURL binding. I don't recommend you solving the problem this way. I instead advice you to use the command line tool to work out exactly what needs to be done and then when it works for you as intended, you translated it into a PHP script. I claim this primarily because --trace and --trace-ascii have no corresponding options in PHP/CURL so you cannot easily compare that your curl requests are matching the ones your browser sends. Like described in chapter 14 in this: http://curl.haxx.se/docs/httpscripting.html And then if you have PHP+CURL related issues still, I'll recommend using the curl-and-php mailing list instead where other PHP users "hang out"...

trying to simulate login to UPS (willing to $pay$ for solution)

Vadim_ghk — 2008-11-30T07:01:51

------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Bug or not bug

Pietro Incardona — 2008-11-29T15:41:27

Re: Re: Re: problem with http basic authentication and multipleredirects

Daniel Stenberg — 2008-11-27T21:18:16

Right. This happens because (lib)curl doesn't consider the path part for when to send the authentication (again) but only the host name so it'll continue to send the same Authorization: as long as the same host is re-used. This seems like a violation against RFC2617 section 2: A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server.

Re: Install Curl

Daniel Stenberg — 2008-11-27T19:14:47

curl is just a curl.exe you can put anywhere you like. If you get the version that supports SSL, you also need to put the SSL DLLs in a dir the exe finds (usually that means in the same dir).

Install Curl

rosy quintero — 2008-11-27T14:42:37

Re: Support for SSL V2

Daniel Stenberg — 2008-11-27T12:26:09

(There's no need to send mails to curl-users-bounces) What weird kind of firewall would "respond" when you're communicating with a remote server? Or are you perhaps talking directly with the firewall's HTTPS server? I guess you'd have to use some sniffer or something to tell since the SSL cert verification fails so in the SSL layer curl cannot tell who it speaks to. It means the server didn't respond with a valid HTTP response, but simply dropped the connection (after it had connected successfully). A proper HTTP response will always at least contain a set of HTTP headers. And please don't top-post.

Re: Support for SSL V2

2008-11-27T07:44:04

Thank you for the answer, but did my firewall (not exactly a server) respond or did it accept the connection ? This can make the difference ... Whay is the meaning of the last lines in the command output: * Empty reply from server * Connection #0 to host xxx.xxx.xxx.xxx left intact curl: (52) Empty reply from server * Closing connection #0 "curl:(52)" appears to be an error code corresponding to "the server didn't reply anything, which here i sconsidered an error" in the man page. I made some more test trying a connection to the firewall with Internet Explorer: when "SSL V2 only" is setted in the advanced options I cannot connect, on the contrary connection succeed when selecting "SSL V3 only". Regards Daniel Stenberg haxx.se> Sent by: To curl-users-bounce the curl tool s< at >cool.haxx.se cool.haxx.se> cc 26/11/08 18:54 Subject Re: Support for SSL V2 Please respond to the curl tool cool. haxx.se> On Wed, 26 Nov 2008, Gianpiero_Drovanti< at >fwceu.com wrote: but to output ? It looks like your server responded fine when curl tried to connect to it using SSLv2. -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html -------------------------------------------------------------------------- NOTICE: this e-mail and any attachments thereto contain information, which is confidential, proprietary, privileged and/or protected from disclosure by intellectual property rights and are intended for the sole use of the recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any dissemination or copying of this message is strictly prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Although we attempt to sweep e-mail and attachments for viruses, it does not guarantee that either is virus-free and Foster Wheeler organization accept no liability for any damage sustained as a result of viruses. ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

libcurl and REALbasic... terrible mix (probably REALbasic's faultthough)

Theodore H.Smith — 2008-11-27T00:23:37

Hi everyone, I've been trying to get libcurl working with REALbasic, for Mac and PC. It's really been a struggle. I've been struggling with this for 2 weeks now. It should be simple. But it hasn't been. I've been trying all sorts of different approaches to figure out what the problem is, when the problem occurs, trying all sorts of different approaches, and getting knocked back with all sorts of different problems each time. First I tried using curl.exe for PC and curl for Mac. Worked great on the Mac. But failed on the PC due to crappy shell interaction, the shell itself wouldn't send the data sometimes. This may be REALbasic's fault or maybe Windows's fault, but... it worked on the Mac and not on PC. So I tried using libcurl as a library. Better success, until I tried making multiple connections. Then I found form data was being lost. I thought it was a fault in libcurl, because it only happened when I turned on NTLM rather than all the time. So I tried using libcurl in plain old C. That worked better. In fact, that worked perfectly. But that give me a bigger problem. Why would it work in a pure C environment, and fail in REALbasic? I spent a long time trying to replicate my RB code in C, but eventually found everything just worked. I realised the flaw can't be in libcurl then! So I tried replicating the C environment in RB. From this, I realised that RB was causing curl lose data because of thread interaction. Which is odd, because REALbasic people keep on saying that REALbasic is SINGLE THREADED. And I only get problems when trying to use multiple connections at once. I tried multiple threads in C, using pthreads. Worked like a charm. But doing the same thing in REALbasic failed. REALbasic can't do pthreads inside of RB, it crashes if you pthread stuff. I tried making a plugin (library written in C++ that works in REALbasic) to do pthreads, that didn't crash, but I was back to where I was before. libcurl was still not sending form-data when sending making multiple connections and using NTLM. So that plugin didn't help. I tried using plain old RB threads, which aren't pthreads, god knows what they are internally (cooperative threads apparantly but even then...). No help either. That just kills connections somehow. So... after all that, I am faced with two choices. 1) Accept that REALbasic's poor threading model, kills off libcurl's ability to make multiple connections no matter how good your intentions are at respecting libcurl's thread design. And just use libcurl one connection at a time. Makes for a worse UI experience... but there you go. 2) Use some kind of external tool, NOT a shell tool because of my terrible experience with Win32 shells and REALbasic. I think an tool that uses IPC sockets (interprocess communication) that I can shuffle data across between RB and the IPC tool, and have that one do the pthreaded libcurl stuff! I simply cannot do number 2). I don't have the time or patience after all the previous disasters. There's only so many failiures a guy can take. In fact if I was wiser, I probably would have given up long ago. I don't suppose anyone has wrapped libcurl in some kind of IPC socketed tool, already? :D Sort of like curl.exe only that it sends and gets data over IPC sockets to the app instead of over the shell. Actually, on second thoughts. Forget that. I think I'm trying too hard. I need to just accept that REALbasic's thread model is terrible. I think this is wiser. -- http://elfdata.com/plugin/ "String processing, done right" ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Re: Re: Re: problem with http basic authentication and multipleredirects

Menner May — 2008-11-26T20:40:13

The circumstances are: The redirects are always staying on the same host. And it's always https. I used the --anyauth and --location options, but not --location-trusted. (and --user, --socks4a, --cookie-jar, -o, -v, -k) As far as I remember, the sequence is now (I can provide some information from the -v output tomorrow.) #1 (original path) GET /path/app?par=filename HTTP/1.x 302 Moved Temporarily Location: /basicbcaaa/protected/basicbcaaa/?par=BASE64ENCODEDSESSION== #2 (redirect to sign on application) GET /basicbcaaa/protected/basicbcaaa/?par=BASE64ENCODEDSESSION== HTTP/1.x 401 Unauthorized WWW-Authenticate: BASIC realm="WWW2 basic" #3 (sign on) GET /basicbcaaa/protected/basicbcaaa/?par=BASE64ENCODEDSESSION== Authorization: Basic aBcDeFaBcDeFaBcDeFaBcDeF HTTP/1.x 302 Moved Temporarily Location: /path/app?par=filename;cookiename=cookievalue Set-Cookie: SSOCookie=BASE64ENCODED-SSOTOKEN==; Path=/ #4 (redirect to original application, with session id) GET /path/app?par=filename;somename=somevalue Authorization: Basic aBcDeFaBcDeFaBcDeFaBcDeF Cookie: SSOCookie=BASE64ENCODED-SSOTOKEN== HTTP/1.x 302 Moved Temporarily Location: /path/app?par=filename #5 (again, original request, this time with some cookies) GET /path/app?par=filename Authorization: Basic aBcDeFaBcDeFaBcDeFaBcDeF SSOCookie=BASE64ENCODED-SSOTOKEN== HTTP/1.x 200 OK Content-Type: application/x-download Menner ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Re: Re: Re: problem with http basic authentication and multipleredirects

2008-11-26T20:36:37

Re: Support for SSL V2

Daniel Stenberg — 2008-11-26T17:47:30

It looks like your server responded fine when curl tried to connect to it using SSLv2.

Support for SSL V2

2008-11-26T13:53:59

Dear All, my corporate auditor is stating that my firewall supports SSL V2 which reportedly suffers from numerous cryptographic flaws and has been deprecated for several years. According to my tests and to literature on my firewall this is not true but my auditor showed me the following curl command output whch, frankly speaking, I don't understand: C:\Users\qzer\>curl -2 -k -vv https://xxx.xxx.xxx.xxx * About to connect() to xxx.xxx.xxx.xxx port 443 (#0) * Trying xxx.xxx.xxx.xxx... connected * Connected to xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) port 443 (#0) * successfully set certificate verify locations: * CAfile: /usr/share/curl/curl-ca-bundle.crt CApath: none * SSLv2, Client hello (1): * SSLv2, Server hello (4): * SSLv2, Client key (2): * SSLv2, Client finished (3): * SSLv2, Server verify (5): * SSLv2, Server finished (6): * SSL connection using DES-CBC3-MD5 * Server certificate: * subject: /O=checkpointmgm..reovye/CN=Checkpoint_cluster VPN Certificate * start date: 2004-03-31 08:51:18 GMT * expire date: 2009-03-31 08:51:18 GMT * common name: Checkpoint_cluster VPN Certificate (does not match 'xxx.xxx.xxx.xxx') * issuer: /O=checkpointmgm..reovye * SSL certificate verify result: unable to get local issuer certificate (20), co ntinuing anyway. zlib/1. 2.3 libssh2/0.15-CVS * Empty reply from server * Connection #0 to host xxx.xxx.xxx.xxx left intact curl: (52) Empty reply from server * Closing connection #0 I there anybody that can explain me if my auditor succesfully connected to my servers and give me an explanation for each lines of the command output ? Thank you and best regards G. -------------------------------------------------------------------------- NOTICE: this e-mail and any attachments thereto contain information, which is confidential, proprietary, privileged and/or protected from disclosure by intellectual property rights and are intended for the sole use of the recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any dissemination or copying of this message is strictly prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Although we attempt to sweep e-mail and attachments for viruses, it does not guarantee that either is virus-free and Foster Wheeler organization accept no liability for any damage sustained as a result of viruses. ------------------------------------------------------------------- List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users FAQ: http://curl.haxx.se/docs/faq.html Etiquette: http://curl.haxx.se/mail/etiquette.html

Re: Digest authorized

Daniel Stenberg — 2008-11-26T12:38:56

Can you provide us with a test account on a similar setup? It seems you're either suffering from a bug (in the server or in libcurl) or you're providing the wrong credentials to the server. We have a number of Digest tests in the test suite and they all work fine. We need to figure out how your case differs from them!