The Token mismatch error is probably a result of a server-side timeout. No link works and I have to manually edit the browser address to return to pMA home. Could it pMA redirect me to home itself?
Better yet, could this error be avoided (for normal uses)?
Please provide the steps to reproduce the bug.
That's a bit hard.
1. Do anything in pMA
2. Wait a few hours
3. Try to do something in pMA again.
I experience that, too. It happens when the php session has timed out, you can reproduce it by deleting the session on the server (e.g. on Debian rm /var/lib/php5/sess_* )
Something similar happens if the MySQL session times out and you take a while to reconnect. If you had multiple tabs open, the other tabs will throw the Token mismatch error
To Raimund's point, this could have to do with an improper assumption of how PHP sessions work. The session garbage collector runs (determined by a likelihood defined by session.gc_probability and session.gc_divisor) based on session.gc_maxlifetime. In older PHP 4 builds, the GC looked at the session file's atime (last accessed time). In newer PHP builds, the GC look at the file's mtime (last modified time).
So unless something is being written to the session on every access (or regularly based on some other criteria), it's possible for an active user's PHP session to be garbage collected.
So some potential fixes would be to modify a session variable on every page load (some people use $_SESSION['LAST_ACCESSED'] for this), change the GC settings, or handle all the session invalidation internally.
We use HTTP authentication, and it's annoying to (multiple times per day) have to manually navigate back to a URL just to get a new session (losing whatever record you were trying to edit). Ad everyone has said, this is typically after a period of inactivity—but occasionally it seems like some operations aren't modifying the session and this happens in the middle of work.
I'm not aware of all of the specifics of how sessions are currently handled, but maybe this will help someone who is pin this issue down.
Also, I believe that this is a duplicate of #4227 -- at least providing that you're also using HTTP authentication.
Justin,
thanks for the hint about last access. phpMyAdmin is setting $_SESSION['last_access_time'] but only with the 'cookie' authentication type.
Can you try this patch?
diff --git a/libraries/plugins/auth/AuthenticationHttp.class.php b/libraries/plugins/auth/AuthenticationHttp.class.php
index 75273b1..abd57ba 100644
--- a/libraries/plugins/auth/AuthenticationHttp.class.php
+++ b/libraries/plugins/auth/AuthenticationHttp.class.php
@@ -227,6 +227,8 @@ class AuthenticationHttp extends AuthenticationPlugin
unset($GLOBALS['PHP_AUTH_PW']);
unset($_SERVER['PHP_AUTH_PW']);
+
return true;
}
Marc,
I've applied that patch and will update you with the results. Sometimes we have a hard time recreating the issue when we're actually trying, so I'll give it a day or two and have my devs keep me updated.
Marc,
I can't say for certain that it hasn't helped at all, but we're still seeing a number of token mismatch errors in our environment. I haven't seen any happen mid-navigation, so it's still possible that these are related to garbage collection. I'll keep an eye out for details.
I have to wonder if it's possible that these issues are related to default session and garbage collection settings on different platforms and packages. Has moving PMA to use it's own session location and handling ever been discussed as a potential solution to avoiding these types of issues with user settings?
The problem is that after some time of inactivity the session goes away, and so refreshing the session only on activity doesn't help much.
I use auth-type "config" and what I find irritating is that you can always open a new tab, but every click in the "old" tab, that is any ajax call, throws the error.
I think there simply could be an interval that keeps the PHP session alive for as long the session lifetime in phpMyAdmin is configured. After all there is $cfg['LoginCookieValidity'].
Otherwise there should be some kind of extra check in each ajax transaction that either allows to re-login without loosing the page you're on if you have to, or just refresh the token in the background in the case of auth-type "config", where there is not even a need to login.
Justin,
thanks for the feedback. Using its own session location and handling has not been discussed, and I have no idea how we could do it and still remain portable on all PHP environments. Do you have a hint for us? (The solution cannot be database-based).
phpMyAdmin 4.2.0-rc1 will contain the proposed patch, for both the auth and config authentication types. We'll see if this is an improvement.
A workaround for this problem has been added to the master branch of our GIT repository. Does that fix the issue for you?
I see the page is automatically reloaded, that seem ok so far.
Duplicate of https://sourceforge.net/p/phpmyadmin/bugs/4227/ and fixed for version 4.3