#3893 Token mismatch error on every action
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;
My guess is that you before switching to HTTP auth, you were using cookie auth. The token mismatch results from the colliding session cookie that is still present in your browser.
To resolve, try the following:
Does this help?
Same problem on newest version of Opera and Internet Explorer, I have removed cache, cookies and deleted all sessions from the tmp/ folder.
That's a bit unusual, i tried with your config details and it worked perfectly fine.
Can you do inspect element and see what is the value attribute of <input type="hidden" name="token" value="?"> . If it is blank or if the value is not same as &token parameter in the url.
I found the problem and it seems it is in the URL.
This is my URL http://127.0.0.1/my_projects/01%20-%20PhpMyAdmin/phpmyadmin/ when it has white-spaces the token send in the links is different then the token in the $_SESSION[' PMA_token '] variable and that is why every action fails. When I remove the whitespaces both tokens are good and it works.
What I can't find is how is the url connected with the generation of the token.
Care to investigate further, Bojan?
Yes I will do that.
I have the same issue.
Last tried with git master (aee3df5).
This occures after a long idle time (e.g. overnight). Initially I was using auth_type=config, and statrted having this error. When switched to cookie auth, then I'm redirected back to login screen every time (no error message, just redirect to blank login). The token in the url is new every time.
My config contains only one server. The url does not contain any whitespace or even punctuation (it's at projectname.development.local/pma/ ).
Tried with different browsers (even those that were not used for this site before), after the problem occurs, it's persistent.
The first time I had this problem, I deleted my previous install (from SF download) and cloned git master. It solved the problem for that one day. Next morning the problem was there on the new install.
Last edit: Marijus Kilmanas 2013-05-16
I also experience same problem. I use Opera. If I had the http auth set, this error message was appeared after a few minutes, when I used another browser tabs and tab with the opened PMA web was idle. When I came back and activate tab with PMA and clicked to some db name on left panel, this message jumped up.
When I changed auth to config, it seems to be OK, but maybe long idle time is needed as Marijus described.
I confirm that this problem doesn't depend on auth type, with auth sets to config, when I came back after 20 minutes to browser tab with PMA, this error message was up again. I think it's serious bug, because it's made PMA completely unusable.
Miroslav,
what's the value of your LoginCookieValidity (can be set in config.inc.php and in your user preferences)? See also php.ini's session.gc_maxlifetime.
From the documentation:
$cfg['LoginCookieValidity']
Type: integer [number of seconds]
Default value: 1440
When I dumped the $cfg["LoginCookieValidity'] at the end of config.inc.php the value is NULL, so I think it will be default (1440) in the application. How can I verify?
The session.gc_maxlifetime is 1440 for web with the installed PMA.
Note: PMA is in user public html folder - /~user/public_html/dbadmin - on linux Apache server with php 5.4.x, so url for PMA web is /~user/dbadmin/
With your settings, you can expect your session to become invalidated after 24 minutes, this is why a new session has to be started by phpMyAdmin, producing a new token (and links previously displayed become invalid and produce a token mismatch).
We want to have token protection against some kind of web attacks, but there is a downside when your session does not last long enough and you're inactive in phpMyAdmin.
I have the same issue with session timeouts and config auth. With config auth, surely it's absolutely irrelevant to require the session for anything? If whatever was there before just rebuild it and carry on silently? With version < 4.0.0 at least I could reload only the main frame and keep my navigation panel unaffected, now I have to refresh the page and ensure I select the correct server, database and table again just to get back to where I was.
In light of @Miroslav's comment above regarding $cfg['LoginCookieValidity'], extending it to a value of MY choosing is still going to be annoying at best due to the following code where someone has decided what's best for me would be a 30 minute limit. I don't want any limit as I don't need one.
// $cfg['LoginCookieValidity'] // should be at most 1800 (30 min) // if ($cf->getValue('LoginCookieValidity') > 1800) { messages_set( 'notice', 'LoginCookieValidity', PMA_lang(PMA_lang_name('LoginCookieValidity')), PMA_lang($strLoginCookieValidityWarning2) ); }I'll end with stating that I fully believe config auth should enable you to work entirely independently of any session goings on behind the scenes.
Last edit: Wandering Zombie 2013-05-20
As @Wandering Zombie said, there was no such behavior for PMA < 4.0. So this is definitely a regression, I must be stuck on latest 3 version. Some solutions:
- if session expires application needs to be reloaded into the required state through http redirect - preferred by me.
- protection can be optional and enabled by default
Current behavior - application stops to work when session expires - is wrong and worses user experience.
I have the suspicion, that simple reload through browser keyboard shortcut doesn't help when the session expired. I try to verify this.
I have the suspicion, that simple reload through browser keyboard shortcut doesn't help when the session expired. I try to verify this.
Simple reload of the page helps when message "Token mismatch" appears. I tested it only for 'config' auth. If the reload will be implemented into the PMA itself, it would be much better.
Problem with the http auth and bad token has maybe other reason then session expiration, because it appears much earlier. I didn't test it.
I also experience same problem with v4.0.2. Both with Firefox & Chrome. When opening another window and connecting to another database server, I get the "token mismatch" error back on the first window/database server. I removed all cookies without success. This is a regression from v.3. Thanks for your help.
Last edit: ro bo 2013-05-30
I doubt that this is a regression. The code for dealing with tokens hasn't changed from the 3.x branch, the only new thing is the check to make sure that the token is valid.
In usability terms it's a big regression. It was annoying in 3.x but now 4.x is without frames, it's not possible to just reload the main frame to restart a session, leaving the navigation pane as it was with your server and database still selected. Today I wasn't even able to use F5 to refresh the page after the token error arose, forcing me to trim the URL manually and then press enter in the address bar to start afresh.
As I've mentioned in an earlier post, config auth should appear to the user as one continuous session regardless of how many real sessions there are behind the scenes. When you're working on big sites with multiple databases and hundreds of tables, reviewing code and then checking tables, to have your session die (because of some arbitrary decision in PMA about what session length I should be allowed to have) is immensely frustrating and makes you lose your train of thought. I may have taken hours to get to looking at a particular row in a table, only to find that some token is no longer valid. Big deal, get over it and let me carry on using PMA as a useful tool (that it can be).
I have the same problem, started from version >= 4.x.x
I can work normally but when I choose to edit a SQL query I get the pop-up SQL-query screen and when I then click Start a new browser window (IE 10) is opened with a phpmyadmin error. From that moment I can't do anything in the Original window, everything I try to do I get token mismatch. If I delete the whole address-bar (without http://localhost/phpmyadmin/) then I can work again, but problem starts again when I edit a SQL-query.
In Chrome (version 27) it works, but when I use the pop-up SQL-query it opens a new TAB (instead of a browser window)
It's working fine on my Windows 7 PC without any problems but not with my macbook air with mountain lion on it. I get the same error "Token mismatch error" on any link i click on. Also, doing "sudo /Applications/XAMPP/xamppfiles/xampp security" will continue just fine without error but could not login to localhost/phpmyadmin, nothing happens when I login and no errors too.
also, this will be my 5th attemp to reply because your login system Openid or not, wont let me post. Some bugs or errors maybe. I hope it will let me post this time.
this solutions works for me.
on PMA session.inc.php, add this line
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/temp'));
and you need to create a folder on the htdocs folder called 'temp' and set the write permissions (or you can choose your own folder)
i'm sure this is not an elegant solutions, but spend almost 2 hrs to get rid the token mismatch popup :D
@outboks
- what is your session.save_path as defined in php.ini?
- are you using phpMyAdmin 4.0.4.1?
@Marc
- as shown in phpinfo, session.save_path is no value, i guess i should edit php.ini instead? and set the value?
- i'm using 4.0.4,default from latest xampp download.