mahara-contributors team mailing list archive

[Aaron Wells <1570179@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

I've recently encountered two issues from clients who are on PHP 5.3 and
have upgraded to Mahara 15.04+ and had serious bugs relating to session
management. These seem to be caused by the changes we made in Bug
1532028 (commit 55a8deb8cbd2 ) to provide non-blocking sessions. Our fix
relied on some undocumented

By default, PHP uses blocking sessions. That is, when you call
session_start(), PHP puts a lock on the session store for your session
ID. This lock is released when you call session_write_close(),
session_destroy(), or your script ends. While the lock is in place, any
other script attempting to access the same session ID will wait until
the lock is released. This gets in the way if you want to run multiple
AJAX scripts simultaneously which use the session (like the ones we use
for loading blocks on a page), or to use AJAX scripts while a long-
running script is running in the background (like for the CSV upload
status bar).

We worked around this by opening and then closing the session multiple
times during a page load. When the session is first launched, we call
session_start() to load $_SESSION, then immediately call
session_write_close(). We do this again when we want to write to the
session, destroy the session, or regenerate the session ID.

However, there's an underlying bug in PHP that causes the session cookie
to be sent out multiple times if you call session_start() and/or
session_write_close() multiple times during a page load. (See
https://bugs.php.net/bug.php?id=31455 and
https://bugs.php.net/bug.php?id=38104 ). So, we tried to work around
this by adding a function that clears out these duplicate page headers.

Anyway, since the duplicate page headers are a bug, our fix relied on
undocumented behavior of PHP. It appears this behavior may not be
correct in some distributions of the PHP binary, particularly in PHP
5.3.3. So, some changes to how we do things may be necessary to avoid
major session problems for sites still on PHP 5.3. Additionally, an
investigation of Mahara's session handler during the course of
addressing these bugs, has shown me some fairly big design flaws in how
we are currently handling sessions. So it will probably save us some
pain down the line if we rewrite the auth/session.php code to be more
robust.

** Affects: mahara
     Importance: Wishlist
         Status: Triaged

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

Title:
  More robust Mahara session handler

Status in Mahara:
  Triaged

Bug description:
  I've recently encountered two issues from clients who are on PHP 5.3
  and have upgraded to Mahara 15.04+ and had serious bugs relating to
  session management. These seem to be caused by the changes we made in
  Bug 1532028 (commit 55a8deb8cbd2 ) to provide non-blocking sessions.
  Our fix relied on some undocumented

  By default, PHP uses blocking sessions. That is, when you call
  session_start(), PHP puts a lock on the session store for your session
  ID. This lock is released when you call session_write_close(),
  session_destroy(), or your script ends. While the lock is in place,
  any other script attempting to access the same session ID will wait
  until the lock is released. This gets in the way if you want to run
  multiple AJAX scripts simultaneously which use the session (like the
  ones we use for loading blocks on a page), or to use AJAX scripts
  while a long-running script is running in the background (like for the
  CSV upload status bar).

  We worked around this by opening and then closing the session multiple
  times during a page load. When the session is first launched, we call
  session_start() to load $_SESSION, then immediately call
  session_write_close(). We do this again when we want to write to the
  session, destroy the session, or regenerate the session ID.

  However, there's an underlying bug in PHP that causes the session
  cookie to be sent out multiple times if you call session_start()
  and/or session_write_close() multiple times during a page load. (See
  https://bugs.php.net/bug.php?id=31455 and
  https://bugs.php.net/bug.php?id=38104 ). So, we tried to work around
  this by adding a function that clears out these duplicate page
  headers.

  Anyway, since the duplicate page headers are a bug, our fix relied on
  undocumented behavior of PHP. It appears this behavior may not be
  correct in some distributions of the PHP binary, particularly in PHP
  5.3.3. So, some changes to how we do things may be necessary to avoid
  major session problems for sites still on PHP 5.3. Additionally, an
  investigation of Mahara's session handler during the course of
  addressing these bugs, has shown me some fairly big design flaws in
  how we are currently handling sessions. So it will probably save us
  some pain down the line if we rewrite the auth/session.php code to be
  more robust.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1570179/+subscriptions