Oh... were you using any db prefixes or combination with a shared db?

For the longest time Setup.php was setting bad cookie prefixes (ie: it didn't exactly fit what the settings for shared users was). Around the time I rewrote Database::tableName, and perhaps a commit sometime later, I did to some modification to the cookie prefix setting code to line up cookie prefixes to use the correct data.

That could have potentially changed the cookie prefix once during a upgrade to 1.13 if you were using database prefixes.

The previous setup was: If db-prefix is set: use "dbname_prefix" If shared-db is set: use "shareddbname" Otherwise just use "dbname"

This incorrectly would set a local cookie prefix even when you enabled the shared db because the if for db prefixes was checked before the shared db was.

New setup: If shared-db is set, 'user' is a shared table, and the shared prefix is set (defaults to the same setting as $wgDBprefix for backcompat): use "shareddbname_sharedprefix" If shared-db is set, and 'user' is a shared table: use "shareddbname" If db-prefix is set: use "dbname_prefix" Otherwise just use "dbname"

This correctly matches the cookie prefix to the settings for shared users.

But as a side effect, when upgrading to 1.13 the cookie prefix will change if you are using a shared user table and are using any type of db prefix.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) ~Profile/Portfolio: http://nadir-seen-fire.com -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)

Brion Vibber wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

jidanni@jidanni.org wrote:

...

Is it "just my imagination" or does upgrading MediaWiki somehow cause users to need to login again? Does it toss its cookies?

Upgrading MediaWiki could update the User class to an incompatible version, which would cause existing User objects cached in memcached/APC/eAccelarator/etc to be invalidated.

I don't believe this would break a session, however; the object should be recreated fresh, authenticated from the login token in the session. If it's a reproducible problem, it should be possible to track it down.

Double-check that it's not a basic problem with sessions; for instance sessions in memcached being broken by an upgrade process that includes restarting memcached, or some change to the memcached hashing (which shouldn't have happened); or an unrelated update to PHP wiping old session data; or the newer MediaWiki version simply using a different session name than the old one.

• -- brion

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjFcqMACgkQwRnhpk1wk45MjACgp2dqiah0nCtxDZUYtFoi7wcD 9y0AoNnjNeUkx663yA+dWKsUf08wt9Oz =bMRd -----END PGP SIGNATURE-----