Page MenuHomePhabricator

PHP session.auto_start = true makes MediaWiki unable to save sessions
Open, LowPublic


On MediaWiki 1.27, 1.28 and current master, if in php.ini you have session.auto_start = 1, then users are unable to login. Logging in just keeps creating new session IDs (as we can see in the session cookie).

As a bonus, if we also have session.hash_bits_per_character = 6, on MediaWiki 1.27 (this doesn't happen on 1.28) when opening the site for the first time (or with private browsing) we get:

Exception encountered, of type "InvalidArgumentException"

If we can't prevent this from happening when session.auto_start is enabled, we should emit at least an informative error message on the login page, and of course an error in the installer.


Either restore support fore session.auto_start=1 (like before MW 1.28), or document that this is not supported, detect it during the installer, and fail at run-time (e.g. from PHPSessionHandler).

Event Timeline

Do you happen to have MediaWiki's session cookie configured to be the same as PHP's?

I haven't touched any variable in LocalSettings.php regarding sessions, just the standard variables set on install.

From IRC:

<no_justification> anomie: Is this...not really a blocker? T159567
<anomie> no_justification: T159567 has been around for a while, hasn't blocked, and hasn't had anyone else reporting it. I suspect it happens if PHP's automatic session cookie collides with MediaWiki's session cookie.
<no_justification> Would you mind de-tagging it with something to that affect?

Krinkle added a subscriber: Krinkle.

Re-adding to remember to backport when this is fixed. The untagging seems somewhat confusing. If this fatal isn't considered blocking, should the task be declined then? Or un-tagged from 1.27 as well meaning we won't backport from master to previous releases if/when this is fixed?

This is still current as of MediaWiki 1.34.2 and PHP 7.3, as reported here

Krinkle updated the task description. (Show Details)
eprodromou added a subscriber: eprodromou.

Seem like the right thing to do is document the incompatibility.