Recent changes to 4877: auto-redirect to login page after timeout

#4877 auto-redirect to login page after timeout

2015-07-10T01:37:23.353000Z

I also get logged out quite frequently when I use phpmyadmin at work. I don't know what my php.ini session timeout setting says but I'll check. I agree with the idea of defaulting to longer, or possibly just using the value of the php setting to automatically configure the phpmyadmin setting (use ini_get).

Hugues' idea of using ini_set to prolong the session seems good! I don't know if that is one of the settings you can change at runtime.

I understand that the docs are giving the security advice of having the session not be too long. Maybe it could ask the user the first time it comes up, and mention the warning then?

#4877 auto-redirect to login page after timeout

2015-05-20T08:59:28.844000Z

just fixed it

#4877 auto-redirect to login page after timeout

2015-05-10T21:11:00.446000Z

Marc,
Could we imagine to get the session.gc_maxlifetime by ini_get?

#4877 auto-redirect to login page after timeout

2015-05-01T13:47:37.086000Z

there is one more thing with this automatic redirect:
if you have more than one open window of phpmyadmin - which is my default, the other windows "close" even if you do queries on the others, so the cookie and the php-session do not expire.

If you don't check your other windows & relogin the one where the session was ended by js, the php session is closed & all other windows don't work any more due to changed session-id.

For you as a background: when I'm preparing queries in applications, I open a few tables in different browser tabs, to have the table structure of all used tables side by side. After that I determine which collums to select, what to join and how based upon the indeces. I think this is a very common way of accessing the databases.

#4877 auto-redirect to login page after timeout

2015-04-29T14:03:27.649000Z

hey, I'm still not speaking about changing the logout time itself, but only the automatic redirect to the login page, which eleminates all query results. For this, I see no reason.
Here we are speaking about phpmyadmin - an application which is used by professionals - mostly on a fixed computer with screen-lock. In the rare circumstances where a public available terminal is used, the user will surely close all browsers, tabs etc. And since on these terminals you can't be sure a keylogger is installed, you should never do this.

#4877 auto-redirect to login page after timeout

2015-04-29T10:15:12.902000Z

Session is used for many things; the most important of them is probably our protection token.

#4877 auto-redirect to login page after timeout

2015-04-28T19:59:19.378000Z

I meant to not require the PHP session data.. What's stored there anyway?

#4877 auto-redirect to login page after timeout

2015-04-28T19:49:43.350000Z

In /setup we have this verification: "Login cookie validity should be set to 1800 seconds (30 minutes) at most. Values larger than 1800 may pose a security risk such as impersonation."

So it seems logical to follow our own security suggestion, in the default value of LoginCookieValidity. I know that default values cannot please everyone, but we try to set them to the best value for the majority of users.

#4877 auto-redirect to login page after timeout

2015-04-28T19:19:07.034000Z

What'd be the disadvantage of defaulting to a day, a week or even longer?

Currently a user would have to change two values instead of one (in php.ini).

Can't the 'session' be restored even if the PHP session data is lost?

#4877 auto-redirect to login page after timeout

2015-04-28T19:12:24.586000Z

Olaf,
you are probably referring to the default value of the LoginCookieValidity directive. According to libraries/config.default.php, this value of 1440 seconds was chosen to match php.ini's same default value for session.gc_maxlifetime. This also has a value of 1440 in the suggested php.ini for production, in PHP 5.3 and 7.0 (see php.ini-production).

We have no way of knowing what is the value of session.gc_maxlifetime for most users, so we used the proposed default value of php.ini.