0

For the adminpanel of our CMS, it turns out some customers like to have a lot longer than aproximately 30 minutes to save data in the administration panel. They get distracted or get a phonecall... and then instead of the data being saved as they expect, they have to log in again and lose changes.

I have tried to keep the session alive with an ajax call Javascript does not call file

That first seemed to work, but eventually does not have the desired effect. If I leave the browser alone, the session dies after 1-2 hours. (I save a timestamp to a textfile every 5 minutes, so I can see exactly when the session stopped being alive). I have been reading a lot about this issue, apparently the garbage collector kills off sessions anyway, if they are around longer than the session.gc_maxlifetime set in php.ini

My consideration is now, to set the session.gc_maxlifetime in the php.ini much higher and then set the session.gc_maxlifetime lower in a php config file for the clients who do not need this. Also for the frontend I don't want the session to be alive for hours. This way I turn it around and controll the sessions that are not supposed to last longer then default.

Would this be good practice? Will this create undesired effects? Any advice on the path to take or possible other solutions?

Community
  • 1
  • 1
LvS
  • 507
  • 1
  • 4
  • 19
  • `to set the session.gc_maxlifetime in the php.ini much higher and then set the session.gc_maxlifetime lower in a php config file for the clients who do not need this.` -- I would think this would almost be a viable way to run it, on the condition that *by default* a much lower value is set, and only if a logged in user is not one needing the extra time. But would it not work better the other way around, so that the normal `maxlifetime` value is used and this value can then be greatly increased only for certain logged in users? – Martin May 07 '17 at 17:49
  • Actually, [this related question](http://stackoverflow.com/questions/1627335/everlasting-sessions-in-php?rq=1) seems to have exactly what you want... – Martin May 07 '17 at 17:50
  • @Martin Yes, that was my first plan, I tried to set the higher maxlifetime fpr the exeption users. Unfortunatly, that did not work. The session was killed long before the 6 hours that I tried to keep the session alive. – LvS May 07 '17 at 17:51
  • (quote:) Normally, what appears to be an everlasting session is two things: a session, which expires pretty soon, **and a very long-life cookie containing an auto-login token.** – Martin May 07 '17 at 17:53
  • I hope you where restarting PHP after updating php.ini? – Martin May 07 '17 at 17:53
  • Well, the difference is, that users on his platform want to stay logged in. That means, from my point of view, that when you visit the site, the cookie is checked and you get logged in again. However, I need my users to still be logged in after x time. Otherwise the $_POST variables get lost by leading them past the login script again. I could recode that in another way, but this seems a more simple solution. – LvS May 07 '17 at 17:55
  • I have not yet updated php.ini. I am considering my options before I decide wich way I go. – LvS May 07 '17 at 17:56
  • I would double check that you where setting the higher max lifetime correctly; as in you where setting these values **before** calling `session_start()` – Martin May 07 '17 at 17:57
  • Yes, my code is: `ini_set('session.gc_maxlifetime', $session_expire); session_set_cookie_params($session_expire); session_start(); `And $session_expire is configured elsewhere. It is passed on, I checked that. – LvS May 07 '17 at 17:59

0 Answers0