mahara-contributors team mailing list archive
-
mahara-contributors team
-
Mailing list archive
-
Message #35622
[Bug 1588613] Re: Mahara not respecting session lifetime setting from admin config page
Did a quick check to see whether the 2 days added on was copied from the
core session cleanup file. It seems that PHP itself doesn't ship with a
shell script for cleaning up session files. Debian does (it's the cron
at /etc/cron.d/php5), and it doesn't add 2 days to that time limit. So
I'm not sure where that came from.
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1588613
Title:
Mahara not respecting session lifetime setting from admin config page
Status in Mahara:
Confirmed
Status in Mahara 15.04 series:
Confirmed
Status in Mahara 15.10 series:
Confirmed
Status in Mahara 16.04 series:
Confirmed
Status in Mahara 16.10 series:
Confirmed
Bug description:
It seems that after the last round of session fixing bugs, Mahara no
longer respects the session lifetime setting that the admin can set on
the site configuration page.
This setting is stored in the database config table as
"session_timeout". It's then retrieved from the database during
session setup, and loaded into the "session.gc_maxlifetime" ini value.
The problem is, we are now initiating the session *before* we launch
the database connection. So when we are setting
session.gc_maxlifetime, session_timeout isn't available, and instead
we use the default value of 1440 seconds = 24 minutes.
The quick workaround is to add your session_timeout setting to your
config.php:
$cfg->session_timeout = 14400; // session timeout of 4 hours
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1588613/+subscriptions
References