new problem with searches being reset

[joanne]

Life in our office is busy and it is not uncommon for me to start setting up the criteria for an advanced search or a search using search builder and get called away to something else.

Yesterday when that happened and I returned to complete the criteria I was getting the message  " As your session has expired/timed out (can't remember which) the search criteria has been reset".  This was not a welcome sight on either occasion as there were quite a few criteria to set up again for each search, and no guarantee that I would get the criteria ( particularly in search builder) fully set up before I was interrupted again.

Eileen thought it was probably caused by https://github.com/civicrm/civicrm-core/commit/ad5fca9eee61bf70b822a58092bdf29ceac03ff8 so she pulled back the commit and I have had no problems since. She tells me that commit will be part of 4.4.5 so unfortunately my reprieve may be only temporary.

By posting this now I am hoping that this patch can be reconsidered before 4.4.5 comes out.  Hopefully there is a way to achieve the aims of the patch without resetting searches.

[totten]

I've tried a few things to reproduce this:

1. Clock manipulation: I build a fresh site, login, open the "Advanced Search" form, and choose a filter (but don't submit). Then I adjust the clock by some amount (an hour, a day, 5 days, a year, ad nauseum). Then I click the "Search" button. For small clock changes, the search goes through fine. For bigger changes, the error is "Access denied" (and a prompt to login). I never get a message about session expiration.

2. Searching through the code, it sounds like this error message:

https://github.com/civicrm/civicrm-core/blob/4.4/CRM/Contact/Controller/Search.php#L69

That error message is a bit imprecise. It looks to mean that validation of the "qfKey" failed -- the validation of qfKey relies on session-data (ie session_id and "privateKey"). Messing up the session is theoretically one way to mess-up those values and therefore break the qfKey validation, but I can't identify a real scenario which does. (Following some discussion with dlobo, I did try hacking the "CiviCRM Session" records in the "civicrm_cache" table. But that doesn't seem to affect qfKey validity, and I don't think it should -- because we don't store session_id or privateKey in that table.)

3. At a high level, I have trouble seeing the relationship between that patch and this error. The discrepancy is that the patch deals with lazy sessions for anonymous users -- but this use-case involves a user who is already authenticated (ie who has a valid session). All of the logic within that patch is prefaced by the conditional, "if (!isset($_SESSION) && PHP_SAPI !== 'cli')".

4. The only suspicious thing (for me) about the patch is that it seems a little overeager to set $_SESSION=array(). I didn't get any feedback on that point ( http://forum.civicrm.org/index.php/topic,31800.msg138373.html#msg138373 ), but you/Eileen could try softening that policy ( http://pastebin.com/Sx7eW5ut )

[joanne]

Eileen, if you read this, it can wait, just let's not deploy 4.4.5 as soon as it is released.

[ken]

@joanne, Eileen,

Did you truncate the Drupal sessions table? (Thus having to log in again.) Applying the patch might change the SSID being employed (sorry about being vague, but I haven't looked at this in over a month.)

Ken

[joanne]

Thanks for the suggestion Ken.

I am not sure that I can re-produce this on anything but my work desktop which points to a computer configuration problem.

As I am at the CiviCRM sprint this will need to wait until I return home.