Login timeout setting

by geniusmusing, Monday, April 29, 2013, 00:27 (4049 days ago)

What is the default time that a user will remain logged in?

I have had to disable the public side so I know whether I am still logged in or I get errors opening an item and it being attempted to be marked read.

Can this be changed?

Login timeout setting

by mkyral, Friday, May 03, 2013, 10:50 (4045 days ago) @ geniusmusing

I also miss some setting there. Currently, I have to login almost each time when I want to see news. Would be great to extend it to at least one day.

Login timeout setting

by micha83x, Monday, October 03, 2022, 20:37 (604 days ago) @ mkyral

This thread is old, but I did not find the question answered elsewhere. Thus, here is my workaround:

  • In file helpers/Authentication.php look for $cookie_expire =.
  • Change the value following the equal sign to a larger value than a month,
  • This leads to a later expiration date for the login cookie in your browser.

I am not proficient in php in any way, but looking at how the config.ini is accessed, you could also add the variable yourself:

  • In file helpers/Authentication.php set $cookie_expire = \F3::get('cookie_expire_seconds');.
  • In file config.ini add a line cookie_expire_seconds = 31536000.
  • Do not delete the new line at end of the config.ini!
  • This results in a expiration time of one year.

Login timeout setting

by jtojnar, Tuesday, October 04, 2022, 16:40 (604 days ago) @ micha83x

Right, the default cookie expiration is one month, but it is not the only factor you need to consider. There is also the session.gc_maxlifetime option in php.ini that defaults to 24 minutes. And, what is worse, even if we changed it in selfoss, the session might still end up being cleaned by PHP when another app runs on the same server and has shorter lifetime. So I would recommend setting it in php.ini yourself.

Login timeout setting

by micha83x, Tuesday, October 04, 2022, 21:23 (603 days ago) @ jtojnar

Ok, thanks for the heads up.
I had a read on the php documentation and now I am quite overwhelmed and scared to break things on my server ;D
For example, I am tempted to enable session.save_path. However, I have no idea about the side effects of disabled garbage collection and having to deal with it via a cron job.
Since my session was never ended after only 24 minutes in the past, I will first try how it works without without modifications to php.ini.
In case, I run into trouble, I will report back.

Login timeout setting

by micha83x, Monday, November 21, 2022, 21:21 (555 days ago) @ micha83x

Well, I started seeing regular session termination on the server side recently since I have other php scripts running on the server. Sadly, I have no direct access to php.ini due to managed hosting, which only allows me to change certain variables in php.ini.

Is there a different way to keep the session alive, e.g. by cron job?

Login timeout setting

by jtojnar, Tuesday, November 22, 2022, 17:11 (554 days ago) @ micha83x

Is there a different way to keep the session alive, e.g. by cron job?

Not really, at least not a simple one. You could copy the session cookie and then replicate a browser request using e.g. curl but that likely will not work on shared hosting so you would need an extra script. And then update the session cookie each time it expired.

I think your best option would indeed be setting session.save_path as you mention (sorry, I missed your last post). Something like the following patch should work after creating the data/cache/sessions directory (though I have not tested it thoroughly):

--- a/src/common.php
+++ b/src/common.php
@@ -11,6 +11,15 @@ use Monolog\Logger;
 
 require __DIR__ . '/constants.php';
 
+ini_set('session.gc_maxlifetime', 30 * 24 * 60 * 60); // 30 days
+// Use a custom session directory so that sessions are not garbage collected by other services.
+ini_set('session.save_path', __DIR__ . '/../data/cache/sessions');
+// Restore the default probability to make GC run in 1/100 requests.
+// This is in case a web host disables GC in favour of a cron script,
+// which would not know about our custom save path.
+ini_set('session.gc_probability', 1);
+ini_set('session.gc_divisor', 100);
+
 /**
  * @param string $message
  *

Of the few downsides, I can see:

  • The session directory being under www root is not a best practice from security stand point since it will be potentially easier to access. If a malicious user gets access to the directory listing, they will see files like sess_15480c88b5d9c9bd5192f939ed05b885, whose names contain a session cookie that can be used to steal active user session. The .htaccess shipped with selfoss will prevent accessing the directory but if you use other web server than Apache, you need to make sure it is properly configured. Nor does selfoss contain any code that allow listing the directory contents. But if you are running other scripts in the same context, you need to trust them that they do not allow bypassing this.
  • The directory will contain an empty file for every time an agent connects to selfoss (even a bot). I would not care about this.
  • Garbage collection might slow down 1% of requests. Probably not a concern either.
  • You will need to apply this change every time you update selfoss.
RSS Feed of thread
powered by my little forum