mahara-contributors team mailing list archive

[Aaron Wells <1588613@xxxxxxxxxxxxxxxxxx>]

This bug is probably more noticeable if you're using the memcache
session handler rather than the default (filesystem) session handler. I
think the memcache session handler uses session.gc_maxlifetime as the
hard expiration date for sessions; whereas in the default filesystem
session handler they may stick around until the garbage handler runs.

-- 
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