Last modified: 2014-09-23 22:34:50 UTC
First noticed here: http://www.mediawiki.org/wiki/Extension_talk:Lockdown When using this hook, robot cannot login with typical bot permissions. Tested with MediaWiki::Bot and MediaWiki::API Perl Modules.
It looks like the solution, upgrade to 1.17, has already been provided.
Just tested in a MW 1.17.0 installation, and the problem persists. Mark, the thread in the page I link is: 'Cannot edit protected pages with Bot in LockDown wiki'.
The problem, then, is in the Lockdown Extension. I suspect (from looking at lockdownSearchableNamespace in Lockdown.php) that you need to adjust you need to adjust $wgNamespacePermissionLockdown
(In reply to comment #3) > The problem, then, is in the Lockdown Extension. I suspect (from looking at > lockdownSearchableNamespace in Lockdown.php) that you need to adjust you need > to adjust $wgNamespacePermissionLockdown I forgot to write down 'true' to effectiveGroups param in MW 1.17 installation. Afterwards, it seems to work. Once this extension is shipped with this params, we can close it (IMO).
r94275
The committed fix (r94275) is not correct. It will still pollute the cache and might affect other parts of MediaWiki. I'll cite what I wrote to the Lockdown-talk-page: > The problem seems quite simple: > * MediaWiki starts loading the logged in user > * While loading it tries to get a list of searchable namespaces and calls the SearchableNamespaces-hook > * Lockdown kicks in and tries to calculate the searchable namespaces, but needs the groups for that > * Lockdown asks the user-object for the groups > * The user-object hasn't finished loading and hasn't loaded the groups yet, so it will only give '*' as the users' groups and caches that. > * Next time Lockdown - or anything at all! - asks for the groups it will get the cached version: '*' > Changing getEffectiveGroups() to getEffectiveGroups(true) tells MediaWiki to ignore the cache (and even repopulate it) and it will be fixed. However, the first time Lockdown asked for the groups it got a wrong answer so that could cause problems. > The solution is a unfortunately a lot less simple. I think the best way will be to let MediaWiki detect it hasn't loaded the groups yet and do that direct. (Or just change the order so the groups will be loaded before even thinking about searchable namespaces.) I've searched a bit more and found a solution: Add $this->clearInstanceCache(); before the end of User::load. It prevents the cache-pollution, but will still give the wrong groups the first time(s?) Lockdown asks for them. That should/could be resolved as stated in the last sentence of my cite.
Created attachment 9010 [details] Patch adding clearInstanceCache() Patch as described in my previous comment.
Adding Daniel Kinzler to cc since I infer he's the Lockdown maintainer.
I think this is the first time I hear about searchable namespaces :) From what I see in the comments, it would indeed make sense to make the user object load groups first, then dfetermin the searchable namespaces. But I do not know what the implications of that are. I suggest to file a request for that as a separate bug report.
