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(a)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-----