I installed Drupal 7.14 on a Debian testing box (wheezy by this date), enabled Simpletest module, installed the examples module and when I run the simpletest_example test I got a fail on the testing batch AJAX call. Latter I found out that the fail is produced because the log-in page is printed on the response, after the expected JSON string.
Then I went to the test results and it said that the log-in form could not be read.
After debugging I found that the call to curl_setopt_array on DrupalWebTestCase::curlInitialize() is failing because of the option CURLOPT_COOKIEJAR set to NULL. curl_setopt_array stops processing options when an option fails and since CURLOPT_RETURNTRANSFER is after CURLOPT_COOKIEJAR in the array it was not set and curl_exec is echoing the downloaded page.
PHP's curl_setopt manual page (http://co.php.net/manual/en/function.curl-setopt.php) claims that by setting CURLOPT_COOKIEFILE to an empty string "no cookies are loaded, but cookie handling is still enabled". So I tried by setting CURLOPT_COOKIEFILE to '' but it still fails, also tried by setting both CURLOPT_COOKIEFILE and CURLOPT_COOKIEJAR to '' and then to NULL but it always fails no matter how I mix it. This is not what the manual says so I filed a bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680260).
I also tried removing CURLOPT_COOKIEJAR and CURLOPT_COOKIEFILE from the options array but then cookies were disabled and userLogin() failed.
Finally I set $this->cookieFile to a temporary file and now everything is working fine. This is how the method looks now:
protected function curlInitialize() {
global $base_url;
if (!isset($this->curlHandle)) {
$this->curlHandle = curl_init();
$this->cookieFile = tempnam(NULL, "drupal-simpletest-cookiejar-");
$curl_options = array(
CURLOPT_COOKIEJAR => $this->cookieFile,
CURLOPT_URL => $base_url,
CURLOPT_FOLLOWLOCATION => FALSE,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_SSL_VERIFYPEER => FALSE, // Required to make the tests run on https.
CURLOPT_SSL_VERIFYHOST => FALSE, // Required to make the tests run on https.
CURLOPT_HEADERFUNCTION => array(&$this, 'curlHeaderCallback'),
CURLOPT_USERAGENT => $this->databasePrefix,
);
if (isset($this->httpauth_credentials)) {
$curl_options[CURLOPT_HTTPAUTH] = $this->httpauth_method;
$curl_options[CURLOPT_USERPWD] = $this->httpauth_credentials;
}
curl_setopt_array($this->curlHandle, $this->additionalCurlOptions + $curl_options);
// By default, the child session name should be the same as the parent.
$this->session_name = session_name();
}
// We set the user agent header on each request so as to use the current
// time and a new uniqid.
if (preg_match('/simpletest\d+/', $this->databasePrefix, $matches)) {
curl_setopt($this->curlHandle, CURLOPT_USERAGENT, drupal_generate_test_ua($matches[0]));
}
}
Comment | File | Size | Author |
---|---|---|---|
#33 | drupal.simpletest-curl-cookiejar.33.patch | 1.49 KB | sun |
#28 | 1671200_28.patch | 1.52 KB | chx |
#18 | core-simpletest-null-cookiejar-1671200_14.patch | 1.56 KB | chx |
#14 | core-simpletest-null-cookiejar-1671200_14.patch | 1.56 KB | jaimealsilva |
#10 | 1671200_10.patch | 1.56 KB | chx |
Comments
Comment #1
jaimealsilva CreditAttribution: jaimealsilva commentedDrupal status, in case is needed as reference:
To run cron from outside the site, go to ...
Comment #2
sunPotentially related: #302075: drupalPost() needs option to POST with empty cookie jar
Comment #3
sunThe provided patch in #0 has been confirmed to work, also on Fedora.
Attached patch performs this change for D8.
Comment #4
sunTemporary backport for D7. (proper one is blocked on #1541958: Split setUp() into specific sub-methods)
Comment #6
pfrenssenThis also affects the contrib Simpletest module in D7.
Comment #7
pfrenssenI rerolled this patch for contrib Simpletest in this issue: #1692836: CURLOPT_COOKIEJAR cannot be NULL on PHP version 5.4.4.
Also changing the title, since this does not only affect Debian.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedI can confirm #4 solves my problem on my tests site.
Comment #9
chx CreditAttribution: chx commentedIt's enough to set the jar if it's not already set. The session tests set it to
$this->cookieFile = file_stream_wrapper_get_instance_by_scheme('temporary')->getDirectoryPath() . '/cookie.' . $uid . '.txt';
. THANKS SO MUCH! I was completely taken aback by curl reporting a 1...Comment #10
chx CreditAttribution: chx commentedMoving the COOKIEJAR line in the array was unnecessary (this does not change #9. at all. makes the patch shorter, that's all).
Comment #11
chx CreditAttribution: chx commentedAlso, someone needs to compile a php.net bug report. This is definitely not Debian, I am running Arch, PHP is 5.4.4 and cURL is 7.26.0
Comment #12
pfrenssenThis issue is probably caused by this bug which was fixed in PHP 5.4.4: CURLOPT_COOKIEFILE '' raises open_basedir restriction.
Comment #13
chx CreditAttribution: chx commentedWe have a problem with the COOKIEJAR and not the COOKIEFILE and also everyone here reports this being still a problem in 5.4.4. But it's very likely the two are related, yes.
Comment #14
jaimealsilva CreditAttribution: jaimealsilva commentedI think is best to use "empty" instead of "!isset" since it also checks for zero length strings and FALSE which are values that make curl_setopt fail.
Comment #16
jaimealsilva CreditAttribution: jaimealsilva commented#14: core-simpletest-null-cookiejar-1671200_14.patch queued for re-testing.
Comment #18
chx CreditAttribution: chx commentedemtpy => empty.
Comment #19
chx CreditAttribution: chx commentedComment #20
jaimealsilva CreditAttribution: jaimealsilva commentedOps! that's embarrassing. Sorry. Thanks chx.
Comment #21
sunComment #22
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks! Moving to 7.x.
Comment #23
SweetchuckI ran into this issue too.
openSUSE 12.1
PHP 5.3.14
PHP cURL Information 7.22.0
PHP cURL SSL Version OpenSSL/1.0.0e
PHP libSSH Version libssh2/1.2.9
by phpinfo()
The patch #18 works well for me.
RTBC++
Comment #24
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedComment #25
chx CreditAttribution: chx commentedIf 5.3.14 is broken too then https://bugs.php.net/bug.php?id=61948 likely broke the COOKIEJAR cos that bugfix is in 5.3.14 too.
Comment #26
sunThe backport is blocked on #1541958: Split setUp() into specific sub-methods (as outlined in #4)
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commentedMy PHP version 5.4.4 (in Fedora, package php-5.4.4-4.fc17.x86_64)
Comment #28
chx CreditAttribution: chx commentedHow is that blocked?
Comment #30
sunComment #31
chx CreditAttribution: chx commentedThanks for the through review and the explanation why my patch didn't work. This just needs fixing because the split is not going to fix this: the only difference between the D7 and the D8 patch is using variable_get to get the public files directory instead of reading it from a class variable. I am throughly intrigued why is that solved by a property and why can we add new properties to D7 test base classes. If we can do that then without the split we can move the public directory into a class property and have the absolute eqiuivalent to D8 patch -- but I have my doubts that'd pass. I will look at this tomorrow.
Comment #32
sunDowngrading this to normal, since D8 has been fixed, and people using PHP 5.4 with D7 are most likely running into many other incompatibilities anyway, and this one is merely about Simpletest only.
As I've pointed out in #4, the backport depends on #1541958: Split setUp() into specific sub-methods, because we want to keep the testing framework as aligned/comparable between D7 and D8 as possible. That issue is RTBC and will be committed either before the new D7 release or shortly after. Once that patch is in, we can backport this patch as-is. So there's no reason for purposively letting the code diverge.
Comment #33
sunThe dependency landed, so here's the clean backport to D7.
Comment #34
chx CreditAttribution: chx commentedOh, awesome.
Comment #35
djdevinThis also applies to D6 running PHP 5.3.14
Patch for D7 worked on D6 with some warnings, but fixed the failures and content getting spit out.
Edit: sorry, wrong issue queue. Meant to post to the contrib thread #1692836: CURLOPT_COOKIEJAR cannot be NULL on PHP version 5.4.4
Comment #36
justageek CreditAttribution: justageek commentedHi, I don't see this:
ever being initialized or being a part of the class definition.
Comment #37
sun@justageek: http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/modules/si...
Comment #38
Xano@justageek: you need Drupal 7.15 for this.
I can confirm this patch works
and it fixes the problem as it should.(apparently it doesn't, as this is a PHP bug).//Edit: some clarification: the patch doesn't fix the bug (as it is in PHP), but it does provide a good workaround as mentioned in #40.
Comment #39
pfrenssenPHP 5.4.6 and PHP 5.3.16 have been released which fix this bug.
references:
Comment #40
pfrenssen@Xano, this issue works around the PHP bug, so that Drupal keeps working on systems that have the affected PHP versions installed.
Comment #41
webchickCommitted and pushed to 7.x as well. Thanks!
Comment #43
phl3tch CreditAttribution: phl3tch commentedFYI, I upgraded to PHP 5.3.17 and still had the issue. Patch #33 works for me though.
Comment #44
alberto56 CreditAttribution: alberto56 commentedHi all,
I'm a bit confused:
- Comment #41 states that this was committed to 7.x on August 18, 2012.
- I am running 7.16, which was released long after comment #41 was posted
- Still, I had the problem of Curl returning "1" instead of an actual response
- I applied the patch in comment #33, which applied to my code
My understanding is that since this was committed to 7.x in august, trying to apply this patch to 7.16 should have resulted in a "detected previously applied patch, revert? (y/n)" message. No?
Thanks,
Albert.
Comment #45
David_Rothstein CreditAttribution: David_Rothstein commented@alberto56, Drupal 7.16 was a security release only, no bug fixes (see the release notes at http://drupal.org/node/1815904, and also see http://groups.drupal.org/node/260803).
This patch is in 7.x-dev so it will definitely be in the next bug fix release... (which will probably be Drupal 7.17 assuming no other security releases happen before then).
Comment #46
Chi CreditAttribution: Chi commentedAs mentioned above the bug appears on PHP 5.3 as well.
Comment #47
brazorf CreditAttribution: brazorf commentedAny chance about the D6 backport of this patch?
Comment #48
XanoFor a D6 backport, please open an issue for the Simpletest project.
Comment #49
kentr CreditAttribution: kentr commentedD6 patch here: https://www.drupal.org/node/1692836#comment-9003679