Comment 4 for bug 1592236

This one's still a problem. The working hypothesis is that something loads up auth/session.php earlier than expected, when $CFG->wwwroot isn't filled in yet, and this causes a session cookie header to be sent out with the default value for the cookie's "path" component. The default is everything between the first and last "/" in the URL. So, if you're visiting an admin page, path "/admin/site/".

Thus a cookie with the name "mahara" and the path "/admin/site/" gets stored by the browser.

Then the user logs in. This causes their session ID to regenerate to a new one. This is handled by sending out a new cookie with the same, domain, and path. But this *doesn't* override the "/admin/site/" cookie, because it has a different path.

Now the user has two cookies named "browser" in their browser's cookie store. One at "/" and one at "/admin/site/". If they visit the page "/admin/site/index.php", their browser will send both cookies, with the "/admin/site/" one first, because it's more specific.

The problem is, PHP doesn't handle multiple session cookies with the same name well. It just reads the first one, and ignores the subsequent ones. The first one is "/admin/site/", with the old session ID. The old session ID is not recognized as valid, so the user is force-logged out.

The big question is, though, how exactly does a header with the wrong path get sent out? In theory, our code to delete duplicate session cookie headers from the response, should delete the ones with the bad path as well. And in theory, when we call the code in auth/session.php that names the cookie "mahara", that same chunk of code should compute the proper path for it based on the wwwroot, which seldom changes.