redekopmark wrote:

I've reverted the update back to 1.16.4 and it fixed the rights issues

.16.5 touched something to do with user rights, so I guess this could be a bug that corrupts the User object cache when the user changes their preferences or something.

Mark, could you check whether this happens with any preference change, as opposed to just with switching to Vector? Could you also check whether your users are just mysteriously losing rights or getting logged out altogether?

redekopmark wrote:

I tried the upgrade to 1.16.5 again tonight, this time i lost my admin rights without touching anything in my preferences (only diff i can think of is that i might not have run the update script right away last time, this time i did) this happened with both the accounts i have one is set to have vector as the default, the other monobook.

Also it doesn't appear as if users are logged out altogether, you can log in, your username appears in the top right corner, you can log out and log in with a diff account and in recent changes your edits are credited to your account. however the user rights that you have are the same as if you were an anon editor.

Is your wiki public? If it is, what is its URL? Can you try contacting me on IRC about this?

redekopmark wrote:

yes it's a public wiki, you can find it at aiowiki.com

another issue has come up, one of my users reported that hew was able to protect a page as a ip address (this is logged here http://www.aiowiki.com/wiki/Special:Contributions/66.168.6.124 and in the recent changes but it's not showing up in the protection log for the wiki). I've emailed him and asked him how he managed to do this but haven't got a response yet.

When I'm on IRC my name is Reddo

Mark narrowed it down to the Lockdown extension, when Lockdown is disabled, it doesn't happen. Updated summary.

Lockdown sets default user options based on the contents of $wgUser, which is definitely a bad idea and something it shouldn't be doing. It calls $wgUser->getEffectiveGroups(), which hits a recursion guard in User::load() and so sets $wgUser->mEffectiveGroups incorrectly. In 1.16.4, $wgUser->mEffectiveGroups happened to be already initialised when the hook was called, but in 1.16.5 it is not.

A workaround is to disable the SearchableNamespaces hook registration in Lockdown.php. I suggest doing that in all branches unless someone can be found who is interested in fixing the extension properly. I'll CC Daniel Kinzler since his name is in the file header.

Lowering priority since we now know there's no problem with the core that would require a release.

skizzerz wrote:

Fixed in r87897, has not been backported to the 1.16 branch as of yet