CiviCRM Community Forums (archive)

I'm getting the following error when I search for members of a group:

Sorry. A non-recoverable error has occurred.
Could not find valid Key

I see that a few people have been having this error and I've followed the suggestions posted without much luck. So I decided to see if I could figure out what is going on that is causing this and would appreciate any help.

I put some debug code in the civicrm/CRM/Core/Key.php file in the get() and validate() functions that basically shows the keys I'm getting, sessionID, etc. As I navigate through various areas of CiviCRM, the $privateKey stays the same (as it should). Then, when I go to one of the areas that causes the error, $privateKey has become a new value. $sessionID, however, is unchanged.

I then added more debug, this time to the function privateKey(), and it appears that $session->get( 'qfPrivateKey' ); is getting back nothing in the times that this error occurs. As a result, it resets the private key in the session to a new value, which, of course, causes the error to cascade back up resulting in the error message being displayed.

So, um, yeah. Any ideas? How could the key get lost in the session? I'm running this under Joomla and have reset the jos_session table on numerous occassions to clear out any sessions. As I mentioned from the debug, though, it is always retrieving the same session id so it's not like the session is getting dumped even. Very weird.

What is the state of the session when $session->get( 'qfPrivateKey' ); gets nothing? can u dump the entire session at that time. I suspect its close to empty

can u check if:

1. u always use example.com OR www.example.com in your urls, not both

2. your sessions in the jos_sessions table is of type longtext

3. your jos_sessions table is utf8

the above 3 are the most common causes.

Do you have any other ajax scripts on the page. at times, i've seen ajax scripts clobber the session

lobo

I've dumped the session object and you're quite correct, it's mostly empty when it gets reset. Well, the session has a lot of stuff in it but the CiviCRM item has 0 elements in it, whereas right after it corrects itself again, it shows it being an array with 6 items in it. As to the three items above:

1. I've got this running on two different servers, one test and one public. The test one only has a local URL without domain or www (just the host name) and, yes, it's consistent. On the public one, I haven't used www in any of the setup. Places I've checked in the configuration for this:

• Resource URLs (http://<site>/joomla/administrator/components/com_civicrm/civicrm/)
• Domain information (<site>)
• Update Directory and Path (Base URL: http://<site>/joomla/)

I've shown what exactly I've got configured there - both sites are the same in that I have /joomla/ as the first part of the URL. In the public instance, this was installed by Fantastico but the test server I installed by hand to emulate the behaviour.

2. Yes, it is longtext: CREATE TABLE `jos_session` (
  `username` varchar(150) CHARACTER SET latin1 DEFAULT '',
  `time` varchar(14) CHARACTER SET latin1 DEFAULT '',
  `session_id` varchar(200) CHARACTER SET latin1 NOT NULL DEFAULT '0',
  `guest` tinyint(4) DEFAULT '1',
  `userid` int(11) DEFAULT '0',
  `usertype` varchar(50) CHARACTER SET latin1 DEFAULT '',
  `gid` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `client_id` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `data` longtext CHARACTER SET latin1,
  PRIMARY KEY (`session_id`(64)),
  KEY `whosonline` (`guest`,`usertype`),
  KEY `userid` (`userid`),
  KEY `time` (`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8.

3. Yes, it is utf8, but it wasn't. It was Latin1 before, but changing it didn't seem to solve the problem.

Note, I've tested this on the demo site and I can't get to repeat. Like I said, though, both these instances are having the same issue. I don't have any special Ajax running - it's a stock installation and pretty much identical to joomla.demo.civicrm.org, other than the addition of the '/joomla' path in the URL.

What's odd is that some of the searches on members work fine. On the production server, I have five groups. If I do a contact search in three of them, they work fine. The other two searches cause the error. If I go through Contacts -> Manage Groups and click on each of the member lists, they all display just fine. However, if I try to print from showing the list of members for the same two groups that fail on search, the print fails with the same error again.

One more note: the production server is running MyISAM (the provider doesn't have InnoDB available) but the test server is running InnoDB. I did, however, get my copy of the test database from the production server and have to switch all the tables to InnoDB, so if there was a data corruption on the production server, that would have been carried across to the test server no doubt.

Just to make sure that the addition of the '/joomla' portion of the URL wasn't causing the issue, on my test setup I just reconfigured it to not have that, but it didn't help.

Maybe there's another place that I'm missing on the URLs? In doing the above step, I notice that one account that I use, which has 'Super Administrator' privileges is still pointing to '/joomla/administrator' for all the menu options in CiviCRM, whereas another account that has 'Manager' permissions in Joomla is getting just '/administrator' for all the menu options. So there must be something off here...

Just a followup - moved it to a new host running InnoDB and it's all good now. Appreciate all the assistance.