Hello,
We are running a private wiki (MW version 1.24.1) so that anonymous users get no rights, and logged in users get the 'user' group rights.
However, we have also set in the LocalSettings file:
$wgAutopromote['editor'] = array(APCOND_INGROUPS, 'autoconfirmed');
and set various permissions for this group.
Additionally we have set :
$wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11');
However, when I log in and look at the special user rights management page for my own userid, I see that I am in no specific group except for the implied group of 'autoconfirmed users' and Administrators. There are checkboxes for the Administrators, Bureaucrats and 'editor' groups, but none of them are ticked. If I tick a checkbox, and then click save, it says the setting has been saved but unchecks the checkbox again.
Secondly, and more worryingly, is that if I log in using the 141.163.4.11 IP address, and look at the special user rights page, it shows everyone as being in the 'Administrators' (sysop) group! If I take out the autopromote from the LocalSettings file, then no-one (other than the original account created during installation) is shown as being in the Administrators group. Very strange.
So, two things, why can we not set anyone in a group on the user rights management page, and why does the autopromote put everyone in the Administrators/sysop group?
Thanks,
John.
(CCing wikitech-l) On 28 February 2015 at 01:04, John Horne john.horne@plymouth.ac.uk wrote:
$wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11');
Wait, what? MediaWiki supports that?! You should not do that.
However, when I log in and look at the special user rights management page for my own userid, I see that I am in no specific group except for the implied group of 'autoconfirmed users' and Administrators. There are checkboxes for the Administrators, Bureaucrats and 'editor' groups, but none of them are ticked. If I tick a checkbox, and then click save, it says the setting has been saved but unchecks the checkbox again.
It sounds like UserRights can't reasonably handle groups that are both implied (e.g. by autopromotion) and actually grant-able to specific users (where the target user already has implied access?). I'm not entirely surprised - I'm not sure we officially support that configuration?
Secondly, and more worryingly, is that if I log in using the 141.163.4.11 IP address, and look at the special user rights page, it shows everyone as being in the 'Administrators' (sysop) group! If I take out the autopromote from the LocalSettings file, then no-one (other than the original account created during installation) is shown as being in the Administrators group. Very strange.
Okay, matching APCOND_ISIP (and APCOND_IPINRANGE) is based on checking $user->getRequest()->getIP(). But take a look at what User::getRequest does: https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/User.p... So it'll determine every user's eligibility for autopromotion... Using the current requester's IP. Depending on who requests a page (or indeed, from which IP), the wiki will have different admins. That's ridiculous.
There probably can't be much more useful behaviour from User::getRequest - a user doesn't have an assigned IP address, and could have made different sorts of actions from different IPs (log in, edit, etc.) - you wouldn't want to autopromote any user account that's ever logged in from that Plymouth University IP, for example. All we can do is look at the current requester's IP. I wonder why we're not just throwing an exception when code tries to call User::getRequest for a User other than the one making the request... Maybe we just shouldn't even have a User::getRequest function at all.
Alex.
On Sat, 2015-02-28 at 03:27 +0000, Alex Monk wrote:
(CCing wikitech-l) On 28 February 2015 at 01:04, John Horne john.horne@plymouth.ac.uk wrote:
$wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11');
Wait, what? MediaWiki supports that?! You should not do that.
Yes, MW allowed me to do this, but reading your reply I can see why it is not something we want to do. It also explains why the 'user list' page seemed to allocate everyone to the administrators group.
We have now changed things a bit in that the 'editor' permissions have been pushed into the 'user' group (most were there anyway).
We also removed any other 'autopromote' settings. By logging in using the default login mechanism, and with the initially created account, I could then set my own account to be administrator and bureaucrat. After that everything looked fine.
However, we are intending to use the Shibboleth extension (as forked on github) as the main login mechanism. When we reapplied this, my groups were gone again! It seems the extension has a bug in that it removes a users groups, but never adds them back again. I have corrected this, and submitted a patch upstream.
So now we are happy. We have Shibboleth login working fine, and the users groups are as they should be and remain so upon login/logout. We are now not using autopromote at all.
Many thanks for your reply,
John.
You're welcome. I wonder how APCOND_ISIP and APCOND_IPINRANGE were expected to work, and if we should deprecate/remove them.
On 28 February 2015 at 23:17, John Horne john.horne@plymouth.ac.uk wrote:
On Sat, 2015-02-28 at 03:27 +0000, Alex Monk wrote:
(CCing wikitech-l) On 28 February 2015 at 01:04, John Horne john.horne@plymouth.ac.uk
wrote:
$wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11');
Wait, what? MediaWiki supports that?! You should not do that.
Yes, MW allowed me to do this, but reading your reply I can see why it is not something we want to do. It also explains why the 'user list' page seemed to allocate everyone to the administrators group.
We have now changed things a bit in that the 'editor' permissions have been pushed into the 'user' group (most were there anyway).
We also removed any other 'autopromote' settings. By logging in using the default login mechanism, and with the initially created account, I could then set my own account to be administrator and bureaucrat. After that everything looked fine.
However, we are intending to use the Shibboleth extension (as forked on github) as the main login mechanism. When we reapplied this, my groups were gone again! It seems the extension has a bug in that it removes a users groups, but never adds them back again. I have corrected this, and submitted a patch upstream.
So now we are happy. We have Shibboleth login working fine, and the users groups are as they should be and remain so upon login/logout. We are now not using autopromote at all.
Many thanks for your reply,
John.
--
John Horne Tel: +44 (0)1752 587287 Plymouth University, UK
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org