Intermittent, ambiguous error "requires cookies" or is it "invalid session keys"?

Fresh, clean install of Drupal 7.61 + CiviCRM 5.7.0 on PHP 7.1

Error is intermittent (maybe every 3rd or so time) when editing contact records like adding a phone number (inline or record save) or clearing caches. Likely other actions trigger the error as well but these are the ones we've discovered so far.

HTTPS is enforced in .htaccess and permanent redirects in place to ensure one URL is used.

No javascript or network console errors. No related apache server errors logged.

The CiviCRM error message is vague and makes little sense. Cookies are enabled in the browser. And is it a cookies or invalid session key issue? It's very strange that it isn't triggered consistently, every time.

I dropped back to PHP 5.6 and haven't been able to trigger this error again so far, so possibly something to do with CiviCRM on PHP 7.1

My guess is something in the session is being lost but it seems very odd @totten @seamuslee ping

added needs:steps to replicate needs:testing sig:bug triaged labels

Just upgraded to 5.7 and PHP to 7.1 and am experiencing the same issue. I can replicate this any time.

Every time I try to access a login only membership renewal page as an anonymous visitor, when I log in. I receive the error and a backtrace shows the same data as reported.

@awasson any chance you can do a screen cast to help us get our heads around this?

I'm using php 7.2 locally on 5.7+ and haven't seen it so there are some factors we need to track down

Yes, I'll do that shortly. I'm just investigating workarounds but here's my setup.

Apache/2.4.35 Drupal core 7.60 CiviCRM 5.7.0 PHP 7.1.23

The site is set up in permissions so that online contributions are not allowed by anonymous visitors so when the visitor arrives at the contribution page, they are provided a login form.

Note: We're also using logintoboggan with this site but I'm not sure that it's Drupal or Logintoboggan that provides the login screen.

My contributions page: https://www.example.com/civicrm/contribute/transact?reset=1&id=3

On login, I'm redirected to: https://www.example.com/civicrm/contribute/transact

So the problem is that the ?reset=1&id=3 is removed when I login.

I'll do a video and post it shortly.

Andrew

@awasson Ah - this might be more of a known problem - I think that is in the drupal side that it mis-directs - wondering if @petednz or @xurizaemon can recall anything about that

https://www.drupal.org/node/1671118 implies this isn't possible with LoginToboggan

There is an answer here that i half suspect is unusable but for reference: https://drupal.stackexchange.com/questions/189239/how-to-retain-querystring-after-login-in-drupal-7

Solution might be to see if you can set logintoboggan to not fire on certain paths?

drupal_get_destination() looks like it would retain the query string parameters though, so I think the comment at https://www.drupal.org/node/1671118 is incorrect. Possibly it was correct in 2012.

You'd have to see what destination LoginToboggan is trying to set - if all went well, you might see ?destination=civicrm%2Fcontribute%2Ftransact%3Freset%3D1%26id%3D3 which decodes to a destination of civicrm/contact/transact?reset=1&id=3 (example only).

I suspect if Drupal is mis-directing, that may lead back to CiviCRM's use of Drupal's hook_menu() to install a single menu callback at civicrm rather than communicating CiviCRM's routes more fully to the host CMS. (If so, whether this is "drupal-side" or "civicrm-side" may depend which side you are standing on .) But you're landing at civicrm/contribute/transact so that may not be relevant - all you need to do is ensure the query string makes it back too - and not have the session stuff mismatch.

Upstream, HTML_QuickForm maintainers rejected a PR to support PHP7 on account of the library is no longer supported: https://github.com/pear/HTML_QuickForm/pull/7 ... There is a PHP7 fork at flack/html_quickform.

I realise we're discussing a tangential issue at the moment, but just to be clear that the originally reported error didn't involve logintoboggan or any other Drupal contrib redirect modules.

The public repository for my project is here https://gitlab.com/virtualrealms/d7civicrm

And installed contrib modules listed here https://gitlab.com/virtualrealms/d7civicrm/tree/master/sites/all/modules/contrib

The repo should make the issue easier to replicate.

Steps to replicate:

• Install repo https://gitlab.com/virtualrealms/d7civicrm on Apache + PHP 7.1
• Enable contrib modules civicrm, civicrm_cron, civicrm_clear_all_caches, ctools, libraries, admin_menu, module_filter, webform, views, views_ui, css_injector, masquerade
• Known (intermittent) error triggers:
  • Edit contact record e.g. add/remove phone number (using either inline edit or save entire record)
  • Clear civicrm caches
• Known resolution: drop back to PHP 5.6

I agree with @brianhay that this is sort of a tangent so I'll continue investigating and if I find something relevant to this issue, I'll report back. If not, I'll report it in a new or existing issue that is more relevant.

I uninstalled Logintoboggan and it is definitely responsible for placing the login form but the login form belongs to Drupal so I suspect it's still related to the issue reported somehow.

Cheers, Anddrew

@brianhay does uninstalling civicrm_clear_all_caches make any difference - it seems a bit omnimous given the issue appears to be caches clearing too aggressively

@eileen I'll retest today and report back but given the error occurs even when editing a contact record (where presumably cache clearing is unnecessary or at least internal to civicrm) then I doubt civicrm_clear_all_caches is implicated. But I will try ...

I just looked at it - it seems unlikely

@brianhay I'm assuming you are not using Redis/ Memcache or anything like that? The symptom looks like session information has been dumped. When using 'Array' as your caching that would be in the civicrm_cache table for a form

@eileen negative on redis/memcache.

The only other variable I thought of was PHP extension differences between 5.6 and 7.1 - the server I'm using has CPanel and it selects PHP default extensions based on the PHP version chosen, so maybe there's a difference there but CiviCRM didn't complain about any missing PHP extensions when attempting to install it on 7.1. Regardless I'll check those as well.

yeah the 5.6 vs 7.1 think is interesting!

The issue seems to be specific to PHP 7.1 (or even the minor release 7.1.23?). Switching to PHP 7.2 solved the problem for me. PHP extensions and php.ini settings between the 2 environments I made sure were identical and I could consistently switch back and forth between PHP 7.1 and 7.2 and the issue would always occur in 7.1 only. No issues in 7.2.

hmm - good digging - I wonder if it is only some 7.1 versions of php - might be a php bug?

mentioned in issue #2759 (closed)

Hi,

Thank you for raising an issue to help improve CiviCRM. As you may know, this issue has not had any activity for quite some time, so we have closed it.

We would like you to help us to determine if this issue should be re-opened:

• If this issue was reporting a bug, can you attempt to reproduce it on a latest version of CiviCRM?
• If this issue was proposing a new feature, can you verify if the feature proposal is still relevant? Did it get the concept-approved label? Have other people also shown interest? Could it be implemented as an extension?

If the answer to either question is yes, please feel free to comment or re-open the issue. Please also consider:

• Is it something that you could help implement, either by sending a patch or hiring someone who can?
• Would you be willing to fund the work, either through a CiviCRM partner, or the Core Team?

Thank you for your help and contributions to CiviCRM.

P.S. This is an automated message, see infra/gitlab issue 20. We understand that automatic responses are annoying, but given the number of open issues as the project evolves, we need a bit of help to triage and prioritise the most relevant issues.

closed