drupalPost() needs option to POST with empty cookie jar

Hmm.... I see the point, but the I'm wondering if putting $clear_cookies into $curl_options would cause confusion.

The reason for this is that at present, whenever $curl_options is mentioned in the code, it means "an array of options for curl_setopt_array()".

The $clear_cookies flag does not correspond to this usage of $curl_options. Rather, it tells curlExec() only to set CURLOPT_COOKIEJAR just before the final curl_exec().

If a $curl_options argument were provided to drupalPost(), would it be merged with the options already sent to curlExec() in drupalPost()?

I agree, $curl_restart is a better name for the option than $clear_cookies.

I don't think the default behaviour of drupalLogin() should change, since this simulates the browser behaviour that occurs most of the time. However, it might make sense to have a $curl_restart option to drupalLogin(), which would then get passed to the drupalPost() in drupalLogin().

This would allow the new code in user.test to be shortened to something like:

// Login user without cookies
$this->drupalLogin('user', TRUE);
$this->assertText(t('Log out'), t('Logged in.'));

This thought did cross my mind when writing the original patch, but I dismissed it because as far as I can see, logging in without cookies only needs to be tested once. However, the number of lines of code with the argument to drupalLogin() (plus the doc string) will probably be less than or equal to the current number of lines of code, and perhaps there are some use cases which are as yet unclear... On balance, I would be minded to give drupalLogin() the new argument, but it's only a marginal preference.

Let me know if you'd like me to roll this into a patch.

Hmm... I've looked at user.test, and noticed that the original code at line 87 (on which I modelled the new code) is:

 // Login user.
    $edit = array();
    $edit['name'] = $user->name;
    $edit['pass'] = $new_pass;
    $this->drupalPost('user', $edit, t('Log in'));

So the drupalLogin() function isn't used there. Before changing this, I'd like to know that there isn't a good reason that it's this way. And as I'd rather have both login snippets consistent, I'll hold off patching for now.

OK, if it's felt that updating user.test along those lines doesn't count as scope creep, I'll try to update the patch later on today.

Here's the latest version of the patch. Changes from the previous version
* drupalLogin() now has a $curl_restart parameter, documented in the same way as the other functions with the parameter
* user.test now uses drupalLogin() for the test of logging in with the new password and the test of logging in without cookies. This requires setting $user->pass_raw explicitly

I've tested hat the new test causes User.test to fail when it's applied.

Just to be clear, when you test the patch, does is cause a test to be failed when the patch at #293612: user_authenticate() should work when $_COOKIE is empty is applied? With this patch applied, the latest patch in this thread passed all its tests, as it should. The patch in this thread is designed to cause a failure in the current version of HEAD.

I've not access to my testing rig at the moment, so I can't tell which of the blank lines in the patch is the wrong one. Will try to look at that this evening.

The issue that this test should prevent regressions to (#293612: user_authenticate() should work when $_COOKIE is empty) is now fixed, so I have rerolled the patch against HEAD and checked that all of the user tests pass.

Just realised I hadn't rolled the patch correctly due to running cvs diff in a subdir. Corrected patch attached.

Here's a new version of the patch. Apart from reworking the code, I think I've addressed the concerns of comment #13, apart from possibly the white space in user.test. There is extra white space in user.test, but I think this matches the pattern of whitespace already in user.test.