2012-10-23 9 views
5

मैंने एक "अजीब" PHP कर्ल व्यवहार देखा है जो मुझे पागल भेज रहा है। असल में मैं जो कर रहा हूं वह कर्ल के साथ एक पाचन प्रमाणीकृत कॉल कर रहा है। यहाँ मेरी कोड के एक उद्धरण है:पाचन कर्ल डाइजेस्ट के साथ दो प्रतिक्रियाएं

curl_setopt($this->c, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST); 
curl_setopt($this->c, CURLOPT_USERPWD, $username . ":" . $password); 

यह ठीक काम करता है और सर्वर वास्तव में संदेश की एक "हाँ, आपके द्वारा दी गई सही प्रमाणिकताएं" प्रकार के साथ वापस आता है। केवल परेशानी है, कच्चे http प्रतिक्रिया थोड़ा अजीब है क्योंकि इसमें शामिल है, वास्तव में, एक के बजाय 2 प्रतिक्रियाएं। यहां बताया गया है curl_exec है ($ this-> ग) बाहर थूक:

HTTP/1.0 401 Unauthorized 
Date: Tue, 23 Oct 2012 08:41:18 GMT 
Server: Apache/2.2.20 (Ubuntu) 
X-Powered-By: PHP/5.3.6-13ubuntu3.9 
WWW-Authenticate: Digest realm="dynamikrest-testing",qop="auth",nonce="5086582e95104",opaque="4b24e95490812b28b3bf139f9fbc9a66" 
Vary: Accept-Encoding 
Content-Length: 9 
Connection: close 
Content-Type: text/html 

HTTP/1.1 200 OK 
Date: Tue, 23 Oct 2012 08:41:18 GMT 
Server: Apache/2.2.20 (Ubuntu) 
X-Powered-By: PHP/5.3.6-13ubuntu3.9 
Vary: Accept-Encoding 
Content-Length: 9 
Connection: close 
Content-Type: text/html 

"success" 

मैं क्यों यह सर्वर (वह है जिसमें यह कहा गया है कि यह प्रमाणीकरण की आवश्यकता है) से पहले प्रतिक्रिया शामिल नहीं मिलता है।

क्या कोई इस मुद्दे पर कुछ प्रकाश डाल सकता है? मैं प्रतिक्रियाओं के संचलन से कैसे बचूं?

चीयर्स

+0

के उत्पादन में मैं बिल्कुल * एक ही समस्या * है में 'cURL जानकारी' प्रविष्टि से अपने PHP द्वारा प्रयोग किया जाता है। यह टिप्पणी संकल्प में कुछ भी नहीं जोड़ती है, लेकिन मैं लोगों को यह बताना चाहता हूं कि यह पूरी तरह से अलग समस्या नहीं है। – Hezad

+0

मैंने अंततः PHP के exec() फ़ंक्शन रैपिंग कमांड लाइन कर्ल कॉल का उपयोग किया। यह आदर्श से बहुत दूर है लेकिन यह प्रोटोटाइप के लिए अच्छा काम करता है: exec ('curl --digest -u the_login: the_password the_url', $ params); फिर भी एक उत्तर के लिए खोज और इंतजार कर रहा है। – Hezad

+0

मैंने अभी इसे वायरशर्क और इसी तरह के सेटअप के साथ परीक्षण किया है, जब आप पाचन प्रमाणीकरण का उपयोग करते हैं तो कर्ल आग 2 अनुरोधों की तरह दिखता है, और पहला कोई प्रमाणीकरण के बिना है। अब सवाल यह है कि curl कमांड लाइन इस प्रतिक्रिया को अनदेखा क्यों करती है और php_curl इसे संलग्न करता है। – gries

उत्तर

2

ऐसा लगता है कि कर्ल की तरह ही व्यवहार किया है अगर आप हेडर के लिए मैं विकल्प का उपयोग:

curl -I --digest -u root:somepassword http://localhost/digest-test/ 

रिटर्न:

HTTP/1.1 401 Authorization Required 
Date: Fri, 31 May 2013 13:48:35 GMT 
Server: Apache/2.2.22 (Ubuntu) 
WWW-Authenticate: Digest realm="Test Page", nonce="9RUL3wPeBAA=52ef6531dcdd1de61f239ed6dd234a3288d81701", algorithm=MD5, domain="/digest-test/ http://localhost", qop="auth" 
Vary: Accept-Encoding 
Content-Type: text/html; charset=iso-8859-1 

HTTP/1.1 200 OK 
Date: Fri, 31 May 2013 13:48:35 GMT 
Server: Apache/2.2.22 (Ubuntu) 
Authentication-Info: rspauth="4f5f8237e9760f777255f6618c21df4c", cnonce="MTQ3NDk1", nc=00000001, qop=auth 
Vary: Accept-Encoding 
Content-Type: text/html;charset=UTF-8 
X-Pad: avoid browser bug 

केवल करने के लिए दूसरा हैडर मिल आप यह कोशिश कर सकता है (बहुत इष्टतम समाधान नहीं):

<?php 

$ch = curl_init(); 
     // set url 
curl_setopt($ch, CURLOPT_URL, "http://localhost/digest-test/"); 
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST); 
curl_setopt($ch, CURLOPT_USERPWD, "root:test"); 


// first authentication with a head request 
curl_setopt($ch, CURLOPT_NOBODY, 1); 
curl_exec($ch);   

// the get the real output 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 
curl_setopt($ch, CURLOPT_HEADER, 1); 
curl_setopt($ch, CURLOPT_HTTPGET, 1); 
$output = curl_exec($ch); 
echo $output; 
0

मैंने एक ही समस्या को मारा, और मुझे लगता है कि यह PHP के libcurl के एक प्राचीन संस्करण के खिलाफ संकलित किया गया था (मेरे मामले में 7.11.0, जो अब लगभग 10 वर्ष पुराना है)। Libcurl (7.2 9.0) के एक और हालिया संस्करण के साथ एक अलग मशीन पर एक ही कोड ठीक था, और मेरी समस्याएं मेरे होस्ट को उपलब्ध नवीनतम (7.30.0) का उपयोग करने के लिए अपने PHP को फिर से कंपाइल करने के बाद समाप्त हो गईं।

यह फ़िक्स a thread on the curl-library mailing list from 2008 द्वारा सुझाया गया था, जहां उपयोगकर्ता ने समस्या को प्रभावित किया गया संस्करण 7.10.6 लेकिन 7.12.1 नहीं। मैंने libcurl changelog around 7.12.0 खोजा है और इस समस्या को ठीक करने के बारे में कोई स्पष्ट प्रविष्टि नहीं ढूंढ पाई है, हालांकि इसे "सामान्य HTTP प्रमाणीकरण सुधार" द्वारा कवर किया जा सकता है। फिर भी, अब मुझे पूरा भरोसा है कि एक पुरानी libcurl समस्या है।

आप देख सकते हैं जो libcurl के संस्करण phpinfo();

संबंधित मुद्दे