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 _______________________________________________ Mailing list: https://launchpad.net/~mahara-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
