Page MenuHomePhabricator

$wgWhitelist* variables no longer have any apparent effect.
Closed, ResolvedPublic

Description

Author: 98matta

Description:
I moved my old wiki directory and created a new directory to test the 1.4 Beta.
I used an existing database. I copied these three lines from my old
LocalSettings.php directory and into the new one created by the install script:

$wgWhitelistAccount = array ( 'user' => 0, 'sysop' => 1, 'developer' => 1 );
$wgWhitelistEdit = true;
$wgWhitelistRead = array ("Special:Userlogin");

The old version of the wiki prevents any non-logged-in user from doing anything
but logging in. The new version does no such thing.


Version: 1.5.x
Severity: normal

Details

Reference
bz996
TitleReferenceAuthorSource BranchDest Branch
mwdd: Only resume containers that have already been createdrepos/releng/cli!133addshoremwdd-dont-show-failed-on-resumemain
Customize query in GitLab

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 7:06 PM
bzimport set Reference to bz996.
bzimport added a subscriber: Unknown Object (MLST).

this is due to the "user group level" patch.

Comment from dupe bug 1043:

Following the steps outlined in http://meta.wikimedia.org/wiki/Preventing_Access
do not work as expected.

From what I can tell, this is due to the default settings of the groupRights
hash located in includes/User.php, in the isAllowed function, line 625. Changing
the value of 'read' from '*' to 'user' seems to fix the problem.

  • Bug 1043 has been marked as a duplicate of this bug. ***

Fixed in 1.4 CVS (for beta2).

This will still need to be dealt with in 1.5, with the new user levels stuff.

wegge wrote:

(In reply to comment #4)

Fixed in 1.4 CVS (for beta2).

This will still need to be dealt with in 1.5, with the new user levels stuff.

The same could be achieved in 1.5 by removing "edit" from the groups Anonymous
and Logged in, so it should just be a metter of documenting this?

$wgWhitelistAccount has now been replaced by the createaccount permission in $wgGroupPermissions.

$wgWhitelistEdit and $wgWhitelistRead may still need to be tweaked or removed in deference to
group config.

I did some testing on this. wgWhitelistRead works the same way in MediaWiki/CVS
as it does in MediaWiki/1.4.5, and I think it still makes sense in the brave new
world of group config. wgWhitelistEdit also still works the same....though it
feels a little peculiar given that one would expect an 'edit' permission. I'll
write up a patch to replace wgWhitelistEdit with isAllowed('edit')

In order for wgWhitelistRead to work properly, you must override the default
permissions by overriding the permissions for group '*'. '*' is the list of
permissions everyone has, even anonymous users. The default value for this is
array('createaccount', 'read'). To override, add this line to your
LocalSettings.php:
$wgGroupPermissions['*'] = array('createaccount');

Created attachment 615
Patch to obsolete wgWhitelistEdit

This removes wgWhitelistEdit, replacing it with wgGroupPermissions('edit')
permission to add on per-group basis

attachment bug996-whitelist.patch ignored as obsolete

Created attachment 645
Patch to obsolete wgWhitelistEdit

Updating patch to remove conflict from latest CVS (previous patch still used
old-style wgGroupPermissions declarations)

Attached:

Applied patch.

$wgWhitelistEdit is now obsolete, and UPGRADE explains what needs to be done to convert
$wgWhitelistAccount, $wgWhitelistEdit, and $wgWhitelistRead settings to new system.