Ben Johnson - 2013-12-18

Hmmm, I just did some additional testing that makes me rethink my previous comment.

My PMA session is currently in this "token mismatch" state, so I inspected the XHR request that is made when I click any navigation hyperlink. The URL actually lacks the Microhistory segment, so the problem may not (always -- or at all) be related.

Here's the URL that the AJAX call is requesting when I click, for example, the "Query" navigation button:

https://localhost/pma/db_qbe.php?db=mydb&token=2e96264983854401250835d2cbcd4dd2&ajax_request=true&ajax_page_request=true&menuHashes=8d6a318d-c4586f22-c5d7ba11&_nocache=1387384860071714141

Again, if I add this line after 468 in /libraries/common.inc.php, here's what happens when I hit the above URL:

var_dump($token_mismatch, PMA_isValid($_REQUEST['token']), $_SESSION[' PMA_token '], $_REQUEST['token']);exit;

boolean true

boolean true

string 'edb4f1d2796f5a001380da8cafbda1f9' (length=32)

string '2e96264983854401250835d2cbcd4dd2' (length=32)

This implies that the $_SESSION[' PMA_token '] value is changing at some point, so it no longer matches the $_REQUEST['token'] value, thereby causing this error.

I dug further to see if I could shed some light on where/when/how $_SESSION[' PMA_token '] is set (and regenerated). From what I can see, $_SESSION[' PMA_token '] can be set in three places only:

- /libraries/session.inc.php (line 109)
- /libraries/session.inc.php (line 123)
- /libraries/plugins/auth/AuthenticationSignon.class.php (line 196)

After marking these locations, I hit F5 in the browser and noticed that my var_dump() of $_SESSION[' PMA_token '] produced a new value. It was 30-60 minutes between requests.

I narrowed the line on which the token is regenerated down to the first of the three lines cited above:

if (! isset($_SESSION[' PMA_token '])) {
    $_SESSION[' PMA_token '] = md5(uniqid(rand(), true));
}

Obviously, $_SESSION[' PMA_token '] cannot be set for this line to be executed, so $_SESSION[' PMA_token '] is indeed being destroyed (or unset()) after some period of time.

I tried var_dump($_SESSION) just before that line, and it looks like this:

array
  'errors' => 
    array
      empty

The question becomes, why is $_SESSION[' PMA_token '] (or all of $_SESSION, perhaps) being destroyed? As far as I am able to discern, PHP is configured for sessions to last up to 2592000 seconds (roughly 1 month), provided that the session cookie is not destroyed.

Further, I did think to check the PHP session ID value during each of these attempts and the value has never changed (even though $_SESSION[' PMA_token '] seems to be regenerated every so often).

These observations almost make it seem as though PMA is destroying the session data after some period of time (rather than the actual PHP session timing-out in some fashion). Is this possible?