#3893 Token mismatch error on every action

[Bojan Petkovski]

I'm getting token mismatch on every link I click, and I can get only to the main menu screen, nothing else is working.

I attach image where you can see the bug and the version of php, mysql and phpMyAdmin I'm using. Also I'm Windows 7 and using xampp 1.8.1 and Chrome/26.0.1410.64.

Also here is the config file I build it with the setup option:

/ Servers configuration /
$i = 0;

/ Server: 127.0.0.1 [1] /
$i++;
$cfg['Servers'][$i]['verbose'] = '';
$cfg['Servers'][$i]['host'] = '127.0.0.1';
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['nopassword'] = true;
$cfg['Servers'][$i]['auth_type'] = 'http';
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';
$cfg['Servers'][$i]['AllowNoPassword'] = true;
$cfg['Servers'][$i]['CountTables'] = true;

/ End of servers configuration /

$cfg['DefaultLang'] = 'en';
$cfg['ServerDefault'] = 1;
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';
$cfg['AllowArbitraryServer'] = true;
$cfg['UserprefsDeveloperTab'] = true;
$cfg['Error_Handler']['display'] = true;

[Marc Delisle]

@outboks

• yes you should (and restart Apache), because now, all your session-based apps (including phpMyAdmin) don't work (unless you are saving your sessions not on disk)
• please inform the XAMPP folks about the missing value in session.save_path, if the php.ini comes from them

[outboks]

@Marc
yes did change the php.ini and restart and it works, thanks Marc, i think this is the proper solution.

when searching the XAMPP support page, i found this thread, basically the same problem i has having earlier, so i just link it to this page as well.

http://www.apachefriends.org/f/viewtopic.php?f=29&t=57299

[cshu]

In my php.ini file it had several options for session.save_path commented out. I uncommented the one that pointed at /tmp.

In order to import .sql files into PMA to populate my dbs I also had to set upload_tmp_dir to /tmp since it was commented out and blank.

After I did these two steps thus far it seems to be working. I am migrating over from the free version of MAMP on MacBook.

[Beltran]

I'm Beltran from ApacheFriends (XAMPP) project. We just released a new version that fixes this issue: 1.8.2-1

http://www.apachefriends.org/en/xampp-macosx.html

I hope it helps!

[Maarten]

After changing session.save_path in php.ini I have still the same problem. Any progress on this problem?

[Kissaki]

I suddenly experienced this issue after working with the updated to version 4 phpmyadmin for some time (hours?). I was using 2 tabs in parallel, which worked.

After a longer pause, suddenly, I got the mentioned token mismatch errors on any further than inital pageload requests.

A warning was pointed out that the php session lifetime was lower than the configured cookie validity time. Which I have fixed by now.

Removing cookies for the domain - although I do not see any session cookies - did not help.

I noticed that when I refresh the page the token is converted from a hash parameter to an URI parameter, and an additional token is added in the URI hash, which differs from the other one.
http://localhost/phpmyadmin/index.php?db=&table=&server=1&target=&lang=en&collation_connection=utf8_general_ci&token=13c93d9916599ced365efcc6a15bce8f#PMAURL-0:index.php?db=&table=&server=1&target=&lang=en&token=041965f4e84eb7489ed641f1e9f420d3

I guess this could be a useful hint in debugging this issue.

My session save path and upload dir are set. And as I said, it worked before.

I am using this on Win7 with a self installed nginx + php-cgi setup.
I am using the current phpmyadmin version 4.0.5.

[Kissaki]

remove

[Kissaki]

I noticed that 6 session files are created just from requesting the phpmyadmin main page - which includes 7 requests to php files as far as I can see.

Isn’t this an unusually high number - and only one session should be opened from phpmyadmin?

Trying to open a link, which gives the invalid token error, creates yet another session file.

[Kissaki]

If anybody wants to disable access token checks (beware of the security implications!):
common.inc.php:487 add $token_mismatch = false;

[Ben Johnson]

This has annoyed me to the point that I have broken-down and sought-out this bug report.

I first noticed this problem after upgrading to 4.0.4.0. Just now, I upgraded to the latest version of PMA (4.0.10.0, as of this writing) and this problem still occurs.

Like the others in this thread, my take is that this is a recent change in behavior. I would have been to the appropriate bug report page long ago were it not the case. Whether it is the result of new functionality or a regression remains to be seen.

Here's what I've tried so far:

1.) Ensure that PHP session data is actually stored to the hard disk when using PMA; not the problem, as session.save_path = /var/lib/php5 (a valid location on my system, and I can see the session data files that PMA is creating within this directory).

2.) Ensure that PHP session cookie expiry time is adequate; not the problem, as session.cookie_lifetime = 0 (per PMA's phpinfo() page).

3.) Ensure that PHP garbage collection is not occurring before the session cookie expiry time. Not the problem, as session.gc_maxlifetime = 2592000 (per PMA's phpinfo() page).

Like other users, I, too, was unable to get back to a working state by hitting F5. Although, after upgrading to 4.0.10.0, F5 does resolve the issue with no further action required. But this causes the entire page to be refreshed, which as others have noted, has its attendant problems.

My system is Ubuntu 12.04 LTS with nginx 1.1.19 and PHP 5.3.10.

Here is my PMA configuration, in case any of it is relevant (perhaps the AJAX setting?):

/ Servers configuration /
$i = 0;

$i++;
$cfg['Servers'][$i]['verbose'] = 'My Server';
$cfg['Servers'][$i]['host'] = '127.0.0.1';
$cfg['Servers'][$i]['port'] = '';
$cfg['Servers'][$i]['socket'] = '';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'config';
$cfg['Servers'][$i]['user'] = 'user';
$cfg['Servers'][$i]['password'] = 'password';

/ End of servers configuration /

$cfg['blowfish_secret'] = '4ebbeaa3125564.12341234';
$cfg['UploadDir'] = '/tmp';
$cfg['SaveDir'] = '';
$cfg['ForceSSL'] = true;
$cfg['ShowPhpInfo'] = true;
$cfg['Import']['allow_interrupt'] = false;
$cfg['Export']['method'] = 'custom';
$cfg['Export']['sql_drop_table'] = TRUE;
$cfg['Export']['sql_include_comments'] = false;
$cfg['DefaultLang'] = 'en';
$cfg['ServerDefault'] = 1;
$cfg['AjaxEnable'] = FALSE;
$cfg['LoginCookieValidity'] = 2592000;

[Marc Delisle]

Ben,
did you try version 4.1.0-rc3 ?

[Ben Johnson]

Thanks for the suggestion, Marc.

I just tried 4.0.1 RC3 and the problem persists.

Each time I try a new version, I copy-over only config.inc.php and I start a new private/incognito browser session and ensure that PMA generates new session data. If this method is for any reason insufficient for this type of testing, please let me know.

To be clear, PMA functions as expected until it is left idle for some period of time, and then I come back and try to click any hyperlink within the interface. I mention this only because it sounds as though the original bug-reporter had this problem "out-of-the-box" (which makes sense if session handling is not working correctly, for example).

I have not been able to discern precisely how long PMA must sit idle for this to occur when I return, but it seems to be about 1 hour. It's time-consuming to test. ;)

This is a local, development-only machine, so I tend to set extremely large resource limits, across-the-board, and I would be surprised if anything was set to 1 hour, with respect to the underlying stack configuration.

[Ben Johnson]

I looked into this in more detail and believe to know the cause of this frustrating condition.

It seems as though the $_REQUEST superglobal is not being set correctly under certain circumstances.

When this "Token mismatch" error appeared most recently, I inserted the following line after line 468 in /libraries/common.inc.php:

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

The output is as follows:

boolean true

boolean false

string '27f2f6c95b8cc00c5c31dcdfea1c7811' (length=32)

null

array
empty

Clearly, $_REQUEST['token'] is empty.

I took a closer look at the request URL, which is as follows:

https://localhost/pma/#PMAURL-29:sql.php?db=mydb&table=mytable&server=1&target=&token=820dd9151993988de30afc3a861a3ee2

I thought to myself, "What is the unusual syntax there, /#PMAURL-29:sql.php?

So, I removed the "#PMAURL-29:" and requested the URL as such:

https://localhost/pma/sql.php?db=mydb&table=mytable&server=1&target=&token=820dd9151993988de30afc3a861a3ee2

and the output is as follows:

boolean true

boolean true

string '27f2f6c95b8cc00c5c31dcdfea1c7811' (length=32)

string '820dd9151993988de30afc3a861a3ee2' (length=32)

array
'db' => string 'mydb' (length=9)
'table' => string 'mytable' (length=18)
'server' => string '1' (length=1)
'target' => string '' (length=0)
'token' => string '820dd9151993988de30afc3a861a3ee2' (length=32)

So, there we have it. For whatever reason, this unusual URL syntax is (at least part of) the problem.

[Marc Delisle]

For PMAURL, refer to http://wiki.phpmyadmin.net/pma/Microhistory.

[Ben Johnson]

It looks as though the period was appended to the link, causing it to return an unknown article. (To wit, http://wiki.phpmyadmin.net/ is down for me at the moment.)

[Marc Delisle]

Sorry, the wiki server is being moved as we speak.

[Chris Edwards]

I was experiencing this same issue in Chrome as well. It turns out I had cookies blocked on localhost in Chrome for some development debugging I was doing and that's what the cause was. This probably isn't the case for the rest of you but that's why I was getting the token mismatch error.

[Justin Beasley]

+1 for this issue. We have a team of 10 spread across browsers and platforms, and everyone receives this message regularly (sometimes after a short time, other times after hours of inactivity). We've never been able to figure out the steps to reproduce the issue, but it's a real pain for all of us. We've been experiencing this ever since upgrading to the 4.x branch (and with each subsequent update, currently on 4.1.1 and just got the message again).

It does seem that frequently we end up with different tokens in the query string and the #PMA hash . . . but at other times, we've seen that not cause any issues at all.

Our configuration is similar to what everyone else has mentioned (PHP 5.3 and identical session settings).

Hoping that someone can figure this out and save our sanity!

[Ben Johnson]

Thanks, Chris; good to know. It seems as though there are two circumstances under which this problem occurs: 1) PHP session-handling is not configured correctly on the web-server, in which case this behavior occurs out-of-the-box (or soon thereafter) and 2) when the web-server or PHP mishandles the "Microhistory" URL syntax in some way.

I'm wondering if anybody else is running PMA on nginx (instead of Apache or LightHTTPd), with a CGI-based PHP environment. If it turns-out that most of the others with this problem are on nginx, it would lend strength to the theory that some web-servers are interpreting the URL (the Microhistory portion of the query string, in particular) differently than others. Perhaps some CGI variable is not being set the same way in all environments, thereby causing PMA to fail in this way in certain configurations.

It bears mention that I have "clean-URL rewriting" enabled on the virtual host that serves PMA. In other words, my URLs look something like this (the "[...]" is a placeholder):

https://localhost/pma/#PMAURL-1:db_structure.php?[...]

rather than something like this:

https://localhost/pma/index.php?#PMAURL-12:db_structure.php?[...]

Of possible import is the fact that in the first instance, there is only one "?" in the URL, whereas in the second, there are two. Of course, this could be a "red herring".

Why does this not happen as soon as the user logs in, rather that happening after some extended period of inactivity? Presumably, the URL format does not change between when the user first logs-in and when this "timeout" occurs. So, what's the trigger?

[Ben Johnson]

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?

[Marc Delisle]

Ben,
if I understand correctly the situation, this might happen from the PMA_secureSession() in libraries/session.inc.php. Can you do some tracing (for example by adding a call to error_log('session id regenerated') to see how many times this is called?

[Ben Johnson]

Thanks for the suggestion, Marc. After putting this measure in place, and coming in to this condition today, it actually seems that the function is not called at all.

I'm starting to think that this problem is not PMA's fault, although I think that it could be handled much more elegantly.

After letting my machine sit overnight, the first thing I wanted to do, before clicking anything in the PMA interface, was to check the directory in which PHP stores its session information for yesterday's session data.

It was somewhat unsurprising to find that yesterday's session information had been expunged. PMA is the only application that stores session data in this location, and I'm the only user on this machine. So, it seems clear that some sort of expiration or garbage collection process is wiping-out the session data after some period of time.

Interesting is the fact that when I clicked a random link in the PMA interface (yielding the "Error: Token mismatch" message), the session data file was re-created, with the exact same name and all the same values, with one exception: the " PMA_token " string.

So, actually, it seems that PMA is correct in invalidating the session. If the session file "disappears out from under" PMA, this is the expected (and seemingly correct) behavior.

Next, I'll try to identify which PHP configuration directive is responsible for causing the session data to be cleared.

In the meantime, perhaps we could put forth ideas as to how PMA might handle this situation more gracefully. Without knowing much about PMA's inner-workings, is there a security-related reason for which PMA cannot simply generate a new token value and then redirect the browser such that the URL contains the newly-generated token value? Would this defeat the token feature's very purpose? Because, in practice, I can't see how deleting the query string from the URL manually, which "fixes" the problem for the session duration by "resetting PMA's state", is any different than doing the same thing programmatically.

[Ben Johnson]

Apologies for spamming the comments here, but it seems that Ubuntu (and/or Debian's) PHP garbage collection handling may be the culprit.

I can't speak for Debian OS on the whole, but in the Ubuntu derivative, there's a cron job that is executed on a scheduled basis, which cleans-up PHP session data. The shell script that is called is /etc/cron.d/php5. This script calls another in turn, /usr/lib/php5/maxlifetime. When I call this script directly, it outputs "24", which represents the number of minutes after which a PHP session data file is considered stale and eligible for destruction.

The script recurses through the various PHP configuration directories on the system and looks for session.gc_maxlifetime values that are larger than the default (hard-coded to 1440 seconds, at the top of the script).

So, I think the cause of this symptom's manifestation in PMA is this garbage collection script. The longer explanation is probably that even though the PMA location in the web-server is configured with session.gc_maxlifetime = 2592000, the garbage collection cron script does not take this configuration into account and instead looks to various php.ini files in an effort to discern the largest value for session.gc_maxlifetime that it can find. This approach "kind of makes sense", because it ensures that garbage collection will not occur prematurely in any scenario (except the one that we have stumbled upon here).

I modified a copy of this script to shed some light on what checks it performs:

apache2
Checking /etc/php5/apache2/php.ini
session.gc_maxlifetime = 1440

cgi
Checking /etc/php5/cgi/php.ini
session.gc_maxlifetime = 1440

fpm
Checking /etc/php5/fpm/php.ini
session.gc_maxlifetime = 1440

The simple fix: set session.gc_maxlifetime to the desired value in the appropriate file, as named above.

Note also that there is an "else" condition for

for sapi in apache2 apache2filter cgi fpm; do

which is

for ini in /etc/php5/*/php.ini /etc/php5/conf.d/*.ini; do

This means that which php.ini to modify depends on your PHP configuration.

[Marc Delisle]

Hi Ben,
your analysis is interesting. I am on Debian 7 and had a look at the script you mention. By the way, normally, PHP does this garbage collection internally and I don't see the need for Debian to do it in another way. A related article is http://www.piglets.org/serendipity/archives/81-Garbage-collecting-sessions-in-PHP.html.

On Debian 7, there is an error in the script! The command is
[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null
\; -delete

which does not work because the -ignore_readdir_race option should be specified before the -type argument. That's why on my system, it has no effect.

With all this said, however, I cannot reproduce the token mismatch error. I even play it rough by deleting session files after my phpMyAdmin login, then doing some action in phpMyAdmin: I get the appropriate "Your session has expired..." message.

[Giovanni Bechis]

I have this error only with remote mysql server when I try to create a user, with servers on the same subnet it works well; I do not think that, in my case, it is strictly related to gc.