This is to announce a new release of UserRightsList.
http://www.mediawiki.org/wiki/Extension:UserRightsList
This extension provides an alternative to the standard User rights management special page. • Bureaucrats can view users as a list instead of searching for a specific user name • Users with account creation privileges can view limited rights for other users they created, if user creation logging is enabled • The user list can be filtered by group membership, username (with % wildcards), and/or date ranges for user_registration (by month).
This version mainly converts the database interaction to use $dbr-
select instead of $dbr->query, so I hope it will solve various
database problems that have been reported. I also added MIT license info (so DanTMan can add this to svn) and a Russian translation submitted at Mediawiki.org.
I've tested it on 1.12.0. Hope it's useful to others. ===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Remind me to commit that a bit later. Or maybe I'll try and remember.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
This is to announce a new release of UserRightsList.
http://www.mediawiki.org/wiki/Extension:UserRightsList
This extension provides an alternative to the standard User rights management special page. • Bureaucrats can view users as a list instead of searching for a specific user name • Users with account creation privileges can view limited rights for other users they created, if user creation logging is enabled • The user list can be filtered by group membership, username (with % wildcards), and/or date ranges for user_registration (by month).
This version mainly converts the database interaction to use $dbr-
select instead of $dbr->query, so I hope it will solve various
database problems that have been reported. I also added MIT license info (so DanTMan can add this to svn) and a Russian translation submitted at Mediawiki.org.
I've tested it on 1.12.0. Hope it's useful to others.
Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On second look it appears the extension is not suitable yet.
The extension does not handle user rights permissions correctly. For 1.12> it won't work correctly because it does not handle $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and $wgGroupsRemoveFromSelf. And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission. On 1.11 this will allow them to change restricted rights, however on 1.11 if your extension is enabled it will allow users with limited permission to change rights, to use that form to alter rights freely.
It also looks like a security hazard in general. Rights are not being checked in the correct places, namely the permissions saving. And it is relying on the checkboxes not showing up as the security feature. In other words, it's got a permissions injection vector. And in simple terms... I could probably right now go to any site running the extension, do a little bit of HTML editing on the rights forms, and edit any permission I want on your site without needing the rights at all. And yes, that does go as far as removing the rights for all your users, promoting myself to bot/sysop/bureaucrat and putting a flat ban on every user. You know, the kind of damage that'll take raw database editing to fix.
And there's some hardcoding of group names, and it's likely that checkboxes are not going to be rendered correctly when anything other than the default groups are used.
The handling of time also appears to be done in a way which is not cross-database compatible, and there is raw use of DISTINCT which I believe we have as a select option.
Is there anything you want to fix, or to any external parties want me to commit so they can fix up the extension?
ps: in_array('userrights',$wgUser->getRights()); would best be written as $wgUser->isAllowed('userrights');
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
DanTMan wrote:
Remind me to commit that a bit later. Or maybe I'll try and remember.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
This is to announce a new release of UserRightsList.
http://www.mediawiki.org/wiki/Extension:UserRightsList
This extension provides an alternative to the standard User rights management special page. • Bureaucrats can view users as a list instead of searching for a specific user name • Users with account creation privileges can view limited rights for other users they created, if user creation logging is enabled • The user list can be filtered by group membership, username (with % wildcards), and/or date ranges for user_registration (by month).
This version mainly converts the database interaction to use $dbr-
select instead of $dbr->query, so I hope it will solve various
database problems that have been reported. I also added MIT license info (so DanTMan can add this to svn) and a Russian translation submitted at Mediawiki.org.
I've tested it on 1.12.0. Hope it's useful to others.
Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Thanks, this is exactly the kind of feedback I need. Getting someone who is more experienced than I am to actually look at the code is a big help.
On May 16, 2008, at 4:48 AM, DanTMan wrote:
On second look it appears the extension is not suitable yet.
The extension does not handle user rights permissions correctly. For 1.12> it won't work correctly because it does not handle $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and $wgGroupsRemoveFromSelf.
I could use some help on these; we're not running 1.12 in production yet (we're slow), and I just did the recoding of this version in a development copy of 1.12. So I'm not familiar with these. Is there a link or something in the distribution I should read?
And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission. On 1.11 this will allow them to change restricted rights, however on 1.11 if your extension is enabled it will allow users with limited permission to change rights, to use that form to alter rights freely.
It also looks like a security hazard in general. Rights are not being checked in the correct places, namely the permissions saving. And it is relying on the checkboxes not showing up as the security feature. In other words, it's got a permissions injection vector. And in simple terms... I could probably right now go to any site running the extension, do a little bit of HTML editing on the rights forms, and edit any permission I want on your site without needing the rights at all. And yes, that does go as far as removing the rights for all your users, promoting myself to bot/sysop/bureaucrat and putting a flat ban on every user. You know, the kind of damage that'll take raw database editing to fix.
Eek! This sounds like the highest priority to fix.
And there's some hardcoding of group names, and it's likely that checkboxes are not going to be rendered correctly when anything other than the default groups are used.
The handling of time also appears to be done in a way which is not cross-database compatible, and there is raw use of DISTINCT which I believe we have as a select option.
I was looking for that and obviously failed to find how to do that.
Is there anything you want to fix, or to any external parties want me to commit so they can fix up the extension?
I can take a crack at fixing some of this, but it sounds like I need some help with best practices.
Jim
ps: in_array('userrights',$wgUser->getRights()); would best be written as $wgUser->isAllowed('userrights');
That should be an easy one.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
DanTMan wrote:
Remind me to commit that a bit later. Or maybe I'll try and remember.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
This is to announce a new release of UserRightsList.
http://www.mediawiki.org/wiki/Extension:UserRightsList
This extension provides an alternative to the standard User rights management special page. • Bureaucrats can view users as a list instead of searching for a specific user name • Users with account creation privileges can view limited rights for other users they created, if user creation logging is enabled • The user list can be filtered by group membership, username (with % wildcards), and/or date ranges for user_registration (by month).
This version mainly converts the database interaction to use $dbr-
select instead of $dbr->query, so I hope it will solve various
database problems that have been reported. I also added MIT license info (so DanTMan can add this to svn) and a Russian translation submitted at Mediawiki.org.
I've tested it on 1.12.0. Hope it's useful to others.
Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Jim Hu wrote:
Thanks, this is exactly the kind of feedback I need. Getting someone who is more experienced than I am to actually look at the code is a big help.
On May 16, 2008, at 4:48 AM, DanTMan wrote:
On second look it appears the extension is not suitable yet.
The extension does not handle user rights permissions correctly. For 1.12> it won't work correctly because it does not handle $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and $wgGroupsRemoveFromSelf.
I could use some help on these; we're not running 1.12 in production yet (we're slow), and I just did the recoding of this version in a development copy of 1.12. So I'm not familiar with these. Is there a link or something in the distribution I should read?
^_^ First stop shop for MediaWiki documentation... MediaWiki itself... I seriously recommend a good IDE with autocomplete and a grep like search function. (If you're at a loss Eclipse with PHP or Aptana Studio with PHP work, NetBeans is supposed to have one but it's not released yet afaik, least I couldn't find it easily)
The absolute best thing for finding out how MediaWiki deals with user rights assigning would be to look in includes/SpecialUserrights.php that's Special:Userrights and when doing a user rights extension you're basically trying to mimic what it does but change around the interface.
Actually... Honestly, I think we should have a $wgUser->canAddGroup( ... ); and $wgUser->canRemoveGroup( ... ); set of helper functions to simplify userrights extensions in a way that won't cause damage when userrights are changed in the backend in later versions.
And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission. On 1.11 this will allow them to change restricted rights, however on 1.11 if your extension is enabled it will allow users with limited permission to change rights, to use that form to alter rights freely.
It also looks like a security hazard in general. Rights are not being checked in the correct places, namely the permissions saving. And it is relying on the checkboxes not showing up as the security feature. In other words, it's got a permissions injection vector. And in simple terms... I could probably right now go to any site running the extension, do a little bit of HTML editing on the rights forms, and edit any permission I want on your site without needing the rights at all. And yes, that does go as far as removing the rights for all your users, promoting myself to bot/sysop/bureaucrat and putting a flat ban on every user. You know, the kind of damage that'll take raw database editing to fix.
Eek! This sounds like the highest priority to fix.
Yup... Your setup of the special page is to. 'createuser' isn't a good permission to base on. If anything it would be 'userrights' but you know what the issue with that is. For the most part that would likely be nothing. And you would do isAllowed, isAnon, isBlocked, readOnly, and checks on the global variables in the start of the execute function. http://svn.nadir-point.com/viewvc/mediawiki-extensions/trunk/WikiVid/Special... The way I do the isAllowed, isBlocked, and readOnly checks is basically the standard afaik. I took the pieces from some of the more maintained extensions.
And there's some hardcoding of group names, and it's likely that checkboxes are not going to be rendered correctly when anything other than the default groups are used.
The handling of time also appears to be done in a way which is not cross-database compatible, and there is raw use of DISTINCT which I believe we have as a select option.
I was looking for that and obviously failed to find how to do that.
Might not be that easy to spot, but if you take a look inside of Database::select(); which appears to be Database::selectSQLText() now (^_^ Yay... finally, the ability to use the helper functions to construct complex cross-database compatible sql queries) it calls makeSelectOptions with the $options you pass and if you check there you'll see you can set array( 'DISTINCT' ) in the options parameter.
Is there anything you want to fix, or to any external parties want me to commit so they can fix up the extension?
I can take a crack at fixing some of this, but it sounds like I need some help with best practices.
Jim
ps: in_array('userrights',$wgUser->getRights()); would best be written as $wgUser->isAllowed('userrights');
That should be an easy one.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
DanTMan wrote:
Remind me to commit that a bit later. Or maybe I'll try and remember.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
This is to announce a new release of UserRightsList.
http://www.mediawiki.org/wiki/Extension:UserRightsList
This extension provides an alternative to the standard User rights management special page. • Bureaucrats can view users as a list instead of searching for a specific user name • Users with account creation privileges can view limited rights for other users they created, if user creation logging is enabled • The user list can be filtered by group membership, username (with % wildcards), and/or date ranges for user_registration (by month).
This version mainly converts the database interaction to use $dbr-
select instead of $dbr->query, so I hope it will solve various
database problems that have been reported. I also added MIT license info (so DanTMan can add this to svn) and a Russian translation submitted at Mediawiki.org.
I've tested it on 1.12.0. Hope it's useful to others.
Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Since the security hole is most important, I'm working on that first:
On May 16, 2008, at 12:56 PM, DanTMan wrote: <snip>
And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission. On 1.11 this will allow them to change restricted rights, however on 1.11 if your extension is enabled it will allow users with limited permission to change rights, to use that form to alter rights freely.
It also looks like a security hazard in general. Rights are not being checked in the correct places, namely the permissions saving. And it is relying on the checkboxes not showing up as the security feature. In other words, it's got a permissions injection vector. And in simple terms... I could probably right now go to any site running the extension, do a little bit of HTML editing on the rights forms, and edit any permission I want on your site without needing the rights at all. And yes, that does go as far as removing the rights for all your users, promoting myself to bot/sysop/bureaucrat and putting a flat ban on every user. You know, the kind of damage that'll take raw database editing to fix.
Eek! This sounds like the highest priority to fix.
Yup... Your setup of the special page is to. 'createuser' isn't a good permission to base on. If anything it would be 'userrights' but you know what the issue with that is. For the most part that would likely be nothing. And you would do isAllowed, isAnon, isBlocked, readOnly, and checks on the global variables in the start of the execute function. http://svn.nadir-point.com/viewvc/mediawiki-extensions/trunk/WikiVid/Special... The way I do the isAllowed, isBlocked, and readOnly checks is basically the standard afaik. I took the pieces from some of the more maintained extensions.
OK, so far... I changed the class :
class UserRightsList extends UserrightsPage {
That lets me reuse what's already in the regular UserRights special page.
New save method:
function save_rights(){ global $wgRequest; $users = $this->findMyUsers(); foreach ($users as $user){ $u = User::newFromId($user['user_id']); if(is_object($u)) { $oldGroups = $u->getGroups(); $newGroups = $wgRequest->getArray('user_'.$user['user_id']); if(is_null($wgRequest->getArray('user_'.$user['user_id']))) $newGroups = array();; // remove then add groups $removegroup = array_diff($oldGroups, $newGroups); $addgroup = array_diff($newGroups, $oldGroups); if (count(array_merge($removegroup, $addgroup)) == 0) continue; $this->saveUserGroups( $u->getName(), $removegroup, $addgroup); } } return true; }
This works in my testing on 1.12. Since saveUserGroups does permission checking, I think this should take care of the hole. What do you think? Meanwhile, I'm working on the other stuff.
Jim ===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
For version 0.4... On May 16, 2008, at 12:56 PM, DanTMan wrote: <extensive snipping below>
The extension does not handle user rights permissions correctly. For 1.12> it won't work correctly because it does not handle $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and $wgGroupsRemoveFromSelf.
should be fixed via indirect use of changeableGroups()
And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission...
should be fixed via per previous message
Yup... Your setup of the special page is to. 'createuser' isn't a good permission to base on.
won't change due to Vampire considerations described previously, unless there's an alternative solution.
And there's some hardcoding of group names, and it's likely that checkboxes are not going to be rendered correctly when anything other than the default groups are used.
fixed, again taking advantage of changeableGroups
The handling of time also appears to be done in a way which is not cross-database compatible,...
I think this is improved, but user_registration is in the schema as a string, not a date
and there is raw use of DISTINCT which I believe we have as a select option.
now moot
ps: in_array('userrights',$wgUser->getRights()); would best be written as $wgUser->isAllowed('userrights');
fixed.
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Jim Hu wrote:
For version 0.4... On May 16, 2008, at 12:56 PM, DanTMan wrote:
<extensive snipping below>
The extension does not handle user rights permissions correctly. For 1.12> it won't work correctly because it does not handle $wgAddGroups, $wgRemoveGroups, $wgGroupsAddToSelf, and $wgGroupsRemoveFromSelf.
should be fixed via indirect use of changeableGroups()
And for 1.11 it is a security issue, because for $wgAddGroups and $wgRemoveGroups to work a user needs the userrights permission...
should be fixed via per previous message
Yup... Your setup of the special page is to. 'createuser' isn't a good permission to base on.
won't change due to Vampire considerations described previously, unless there's an alternative solution.
Vampire considerations?
Best solution would be to use the same kind of permissions that Special:Userrights requires.
Actually, I think you could get away with inheriting from UserrightsPage, override __construct to pass a different name, and then just override switchForm and editUserGroupsForm. In other words theoretically you could basically override the form displaying functions, and leave all the complex rights handling functions to the UserrightsPage form. /Anyone think a generic version of some special pages for overriding would be good?/
And there's some hardcoding of group names, and it's likely that checkboxes are not going to be rendered correctly when anything other than the default groups are used.
fixed, again taking advantage of changeableGroups
The handling of time also appears to be done in a way which is not cross-database compatible,...
I think this is improved, but user_registration is in the schema as a string, not a date
I believe MediaWiki stores the times in different ways for different databases. Best thing to do would be to grab the entire timestamp, then use wfTimestamp to convert it to a format which you can then use.
and there is raw use of DISTINCT which I believe we have as a select option.
now moot
ps: in_array('userrights',$wgUser->getRights()); would best be written as $wgUser->isAllowed('userrights');
fixed.
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
On May 17, 2008, at 3:27 AM, DanTMan wrote: <snip>
won't change due to Vampire considerations described previously, unless there's an alternative solution.
Vampire considerations?
Best solution would be to use the same kind of permissions that Special:Userrights requires.
Here's how the vampire model works on our wikis, taking the UserRightsList 0.4 code changes into account. In LocalSettings.php:
$wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['user']['createaccount'] = true; $wgGroupPermissions['*']['edit'] = false; $wgAddGroups['user'][] = 'student'; $wgRemoveGroups['user'][] = 'student'; $wgGroupPermissions['student']['createaccount'] = false;
The key feature is that I can create an account for a professor, who can then create accounts for her students and change their permissions to 'student'. The only difference being that 'student' can't create accounts or manage permissions. But I want that professor to ONLY see the privileges for the accounts she created, and it's just a lot more usable for her if she sees just her users and not everyone in the system. I'm not seeing how to do that by what you're suggesting. The only place I'm seeing the information about who those users are is in the creation log. Is it somewhere else that I'm missing?
I understand that other users who want a UI like what I've written may not want that, and if it's something that makes this unsuitable for svn, perhaps I can modify the setup so that you have to turn vampire permission management on as a conscious choice. I wonder what people would think of a $extVampire or $wgVampire global? ;) Or I guess it could be done with a hook in the extension itself.
... this makes me wonder ... has there been consideration of making a $wgExtGlobals array for extensions to use?
Actually, I think you could get away with inheriting from UserrightsPage, override __construct to pass a different name, and then just override switchForm and editUserGroupsForm. In other words theoretically you could basically override the form displaying functions, and leave all the complex rights handling functions to the UserrightsPage form. /Anyone think a generic version of some special pages for overriding would be good?/
Hmm... my sense is that while this would work, it would be kinda ugly with the current version of SpecialUserRights (1.12 anyway), since there's a bunch of stuff in execute that would be run but ignored. I think a generic version could possibly be set up so that mods like what I'm trying to do are easier by taking more of the code in execute into more granular methods that can be overridden.
But in general, I like the idea of generic special pages designed with overriding possibilities in mind. <snip>
I think this is improved, but user_registration is in the schema as a string, not a date
I believe MediaWiki stores the times in different ways for different databases. Best thing to do would be to grab the entire timestamp, then use wfTimestamp to convert it to a format which you can then use.
OK... I'll look into that. <snip>
Jim
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
That is against how MediaWiki works. Every account is part of the user group. And inheritance is done with true always overriding false. In other words, because a student is a user even though createaccount is set to false for them, the fact that they are a user which has createaccount set to true means that they are allowed to create an account. You can't force that off. That's not how MediaWiki's permissions system works, and if the extension is based off that bad assumption then it definitely won't go into svn cause that's the kind of thing that will only work if you hack MediaWiki to work that way, and hacks aren't supported.
Additionally, it's pointless to try and create an extension with a more limited way to manage permissions based off the Userrights stuff. Because if someone can use your form, then can just as easily access the build in Special:Userrights and edit permissions with what they are allowed to do. Restricting that within a extension's special page is pointless because all it gives you is a false sense of security that doesn't exist.
Globals are globals, there is no need for an array. But normally it's done in the form $eg/ShortExtensionName/*GlobalName*. Where eg stands for 'Extension Global' to match with the 'Wiki Global' in MediaWiki.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
On May 17, 2008, at 3:27 AM, DanTMan wrote:
<snip>
won't change due to Vampire considerations described previously, unless there's an alternative solution.
Vampire considerations?
Best solution would be to use the same kind of permissions that Special:Userrights requires.
Here's how the vampire model works on our wikis, taking the UserRightsList 0.4 code changes into account. In LocalSettings.php:
$wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['user']['createaccount'] = true; $wgGroupPermissions['*']['edit'] = false; $wgAddGroups['user'][] = 'student'; $wgRemoveGroups['user'][] = 'student'; $wgGroupPermissions['student']['createaccount'] = false;
The key feature is that I can create an account for a professor, who can then create accounts for her students and change their permissions to 'student'. The only difference being that 'student' can't create accounts or manage permissions. But I want that professor to ONLY see the privileges for the accounts she created, and it's just a lot more usable for her if she sees just her users and not everyone in the system. I'm not seeing how to do that by what you're suggesting. The only place I'm seeing the information about who those users are is in the creation log. Is it somewhere else that I'm missing?
I understand that other users who want a UI like what I've written may not want that, and if it's something that makes this unsuitable for svn, perhaps I can modify the setup so that you have to turn vampire permission management on as a conscious choice. I wonder what people would think of a $extVampire or $wgVampire global? ;) Or I guess it could be done with a hook in the extension itself.
... this makes me wonder ... has there been consideration of making a $wgExtGlobals array for extensions to use?
Actually, I think you could get away with inheriting from UserrightsPage, override __construct to pass a different name, and then just override switchForm and editUserGroupsForm. In other words theoretically you could basically override the form displaying functions, and leave all the complex rights handling functions to the UserrightsPage form. /Anyone think a generic version of some special pages for overriding would be good?/
Hmm... my sense is that while this would work, it would be kinda ugly with the current version of SpecialUserRights (1.12 anyway), since there's a bunch of stuff in execute that would be run but ignored. I think a generic version could possibly be set up so that mods like what I'm trying to do are easier by taking more of the code in execute into more granular methods that can be overridden.
But in general, I like the idea of generic special pages designed with overriding possibilities in mind.
<snip>
I think this is improved, but user_registration is in the schema as a string, not a date
I believe MediaWiki stores the times in different ways for different databases. Best thing to do would be to grab the entire timestamp, then use wfTimestamp to convert it to a format which you can then use.
OK... I'll look into that.
<snip>
Jim
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On May 17, 2008, at 3:28 PM, DanTMan wrote:
That is against how MediaWiki works. Every account is part of the user group. And inheritance is done with true always overriding false. In other words, because a student is a user even though createaccount is set to false for them, the fact that they are a user which has createaccount set to true means that they are allowed to create an account. You can't force that off. That's not how MediaWiki's permissions system works, and if the extension is based off that bad assumption then it definitely won't go into svn cause that's the kind of thing that will only work if you hack MediaWiki to work that way, and hacks aren't supported.
I could have sworn that it worked in an earlier version of MW, but I see that setting
$wgGroupPermissions['student'] = false;
behaves just like you say it does. However, it was easy to whip up an extension to modify this behavior without hacking MW, by hooking at UserGetRights.
http://www.mediawiki.org/wiki/Extension:RestrictiveRights
Obviously, I wish that was the default - I think admins expect that if they explicitly turn something off in LocalSettings, it should not be overridden by something else. But that's just me.
Additionally, it's pointless to try and create an extension with a more limited way to manage permissions based off the Userrights stuff. Because if someone can use your form, then can just as easily access the build in Special:Userrights and edit permissions with what they are allowed to do. Restricting that within a extension's special page is pointless because all it gives you is a false sense of security that doesn't exist.
I'm not going to update the mediawiki.org page yet, since I figure it's likely that you will find other problems (unless you're sick of this and have given up!), but I have a test revision if you're willing to keep looking at these
http://trimer.tamu.edu/jh/UserRightsList.0.5a1.tgz
I created an global variable that can be set to allow users who do not have userrights to modify specific subsets of group membership of users they created. For my setup, I use:
$egUserRightsListChGrp['user'][] = 'student';
Inside the extension, I modify $wgAddGroups and $wgRemoveGroups based on $egUserRightsListChGrp, but since this is local to the extension, it does not affect access to Special:Userrights.
I also changed the date handling based on your suggestions, and did some other stuff to aid independence from mysql. But I don't have any installations to test those on.
I hope I'm getting closer to addressing your concerns.
JH
<snip>
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
That restrictive rights extension is doomed to be filled with bugs. Especially since you are using ! instead of an explicit === false test. That's not explicit false, that there will remove rights even if permissions are not set. And there's going to be a horrible amount of issues with how rag-tag the list of rights are by default. You're also going based on the order of things in the array. Which is not something you should be basing on because there's no guarantee of what order things are going to go in with the rights array. So, theoretically if someone was a sysop, meaning they have *, user, autoconfirmed, sysop in their array since 'sysop' comes last because 'sysop' has no 'edit' explicitly set anyone you give sysop will not be able to edit. Additionally, since autoconfirmed has absolutely nothing set except autoconfirmed, once a user account has been active for 4 days or over, a user account on your extension should suddenly lose it's ability to do anything on the wiki, including view it.
Though I do thank you for pointing out UserGetRights, that would have made my semi-shared permissions model a lot easier when I built it in the past.
It honestly looks like you're overcomplecating the permissions model in MediaWiki. You're looking at the perspective of creating plain no-rights accounts, and letting them create restricted accounts which have extra flags. Honestly that is complete insane. You're trying to give a default rights group more control over a non-default flag, which in a proper permissions model is supposed to signify more permissions over the default inclusive group. Honestly your rights model would be better handled just by giving professors a 'professor' flag which enables them to create accounts and if needed put them into a student group. But that shouldn't restrict rights in any way, just add more, like editing the wiki or something.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
On May 17, 2008, at 3:28 PM, DanTMan wrote:
That is against how MediaWiki works. Every account is part of the user group. And inheritance is done with true always overriding false. In other words, because a student is a user even though createaccount is set to false for them, the fact that they are a user which has createaccount set to true means that they are allowed to create an account. You can't force that off. That's not how MediaWiki's permissions system works, and if the extension is based off that bad assumption then it definitely won't go into svn cause that's the kind of thing that will only work if you hack MediaWiki to work that way, and hacks aren't supported.
I could have sworn that it worked in an earlier version of MW, but I see that setting
$wgGroupPermissions['student'] = false;
behaves just like you say it does. However, it was easy to whip up an extension to modify this behavior without hacking MW, by hooking at UserGetRights.
http://www.mediawiki.org/wiki/Extension:RestrictiveRights
Obviously, I wish that was the default - I think admins expect that if they explicitly turn something off in LocalSettings, it should not be overridden by something else. But that's just me.
Additionally, it's pointless to try and create an extension with a more limited way to manage permissions based off the Userrights stuff. Because if someone can use your form, then can just as easily access the build in Special:Userrights and edit permissions with what they are allowed to do. Restricting that within a extension's special page is pointless because all it gives you is a false sense of security that doesn't exist.
I'm not going to update the mediawiki.org page yet, since I figure it's likely that you will find other problems (unless you're sick of this and have given up!), but I have a test revision if you're willing to keep looking at these
http://trimer.tamu.edu/jh/UserRightsList.0.5a1.tgz
I created an global variable that can be set to allow users who do not have userrights to modify specific subsets of group membership of users they created. For my setup, I use:
$egUserRightsListChGrp['user'][] = 'student';
Inside the extension, I modify $wgAddGroups and $wgRemoveGroups based on $egUserRightsListChGrp, but since this is local to the extension, it does not affect access to Special:Userrights.
I also changed the date handling based on your suggestions, and did some other stuff to aid independence from mysql. But I don't have any installations to test those on.
I hope I'm getting closer to addressing your concerns.
JH
<snip>
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On May 18, 2008, at 9:47 AM, DanTMan wrote:
That restrictive rights extension is doomed to be filled with bugs. Especially since you are using ! instead of an explicit === false test.
changed.
That's not explicit false, that there will remove rights even if permissions are not set. And there's going to be a horrible amount of issues with how rag-tag the list of rights are by default. You're also going based on the order of things in the array. Which is not something you should be basing on because there's no guarantee of what order things are going to go in with the rights array. So, theoretically if someone was a sysop, meaning they have *, user, autoconfirmed, sysop in their array since 'sysop' comes last because 'sysop' has no 'edit' explicitly set anyone you give sysop will not be able to edit. Additionally, since autoconfirmed has absolutely nothing set except autoconfirmed, once a user account has been active for 4 days or over, a user account on your extension should suddenly lose it's ability to do anything on the wiki, including view it.
I don't think you understand the way this works, and perhaps I need to reword the documentation. I'm using explicit to mean (isset($wgPermissions[group][action]) && ! $wgPermissions[group] [action]) as opposed to just (! $wgPermissions[group][action]).
The scenarios you posit will not happen because sysop has no edit key in the $wgPermissions array. The extension never tries to unset $wgPermissions[sysop][edit], and if it did, it would have no effect because $wgPermissions[sysop][edit] isn't set in the first place. The edit permission for sysop inherits from user. Similarly, autoconfirmed won't be affected because User->getGroups, unlike User-
getEffectiveGroups only looks at what's in the groups table. Which
means that it also doesn't return user or *. I guess that means that it doesn't allow restricting user more than *, but that's not something I'm interested in changing.
Since it only unsets elements from the $wgPermissions array, I don't see how it's dependent on the order of the array.
Though I do thank you for pointing out UserGetRights, that would have made my semi-shared permissions model a lot easier when I built it in the past.
I'm glad you're getting something positive out of this exchange... it's only been there since 1.11.
It honestly looks like you're overcomplecating the permissions model in MediaWiki. You're looking at the perspective of creating plain no- rights accounts, and letting them create restricted accounts which have extra flags. Honestly that is complete insane. You're trying to give a default rights group more control over a non-default flag, which in a proper permissions model is supposed to signify more permissions over the default inclusive group. Honestly your rights model would be better handled just by giving professors a 'professor' flag which enables them to create accounts and if needed put them into a student group. But that shouldn't restrict rights in any way, just add more, like editing the wiki or something.
In some cases it is easier to do things the way you suggest, and I said so in the usage section of the page for the extension. It's not easier in our actual use case, which we've been doing for over a year, where the students represent a very minor component of the user community - the majority are scientists who haven't considered using the wikis for teaching - and we want our users to spread account registration through the community. The way we're doing it, only the subset of those users who want to have more restricted accounts for their students even have to learn ANYTHING about the rights system. If they have to elevate the users they create to another group, it's not going to happen.
I'm sure there are other ways to do it; perhaps by hooking at AddNewAccount to automate adding new users to a default group with the permissions I now give to user. Implementing that approach, however, means going back over the database and upgrading all the preexisting nonstudent accounts to an additional group. And it seems to me that would make managing permission subsets messier. To fully implement that allowing for other possible configurations, I'd end up with user being just * with a registered account, default with what user has now, and some messy subset of groups with permutations of positive permissions beyond user.
While that could be done, I'm not going to do it just because you keep invoking a "proper permissions model". If you have some source for what a "proper permissions model" is and why alternative models are improper, please point me to something to read, and I'll look at it. Just invoking the term doesn't help me understand why what I'm doing is improper rather than just different. I'm a biologist, not a computer scientist, but to the extent that I can understand what I can find via googling various permutations of "permissions model inheritance design", there are alternative models, and I'm seeing papers that argue against unconditional permissions inheritance. Allowing admins to create groups where inherited permissions are revoked makes it easier to modify the permissions model as new circumstances arise - that's exactly how it came up for us.
Having non-default groups with fewer permissions at all is the only thing in RestrictiveRights. Controlling who has permission to change group membership is in UserRightsList. The two are both needed for my permissions model, but they're separate issues, and the two extensions should work without each other... which is why I separated them. The management of a subset of users based on the creation log doesn't have to be applied to the group user.
Finally, I really appreciate your guidance on the code, but I'd also appreciate it if you'd leave my sanity, or lack thereof, out of future discussion.
JH
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
On May 17, 2008, at 3:28 PM, DanTMan wrote:
That is against how MediaWiki works. Every account is part of the user group. And inheritance is done with true always overriding false. In other words, because a student is a user even though createaccount is set to false for them, the fact that they are a user which has createaccount set to true means that they are allowed to create an account. You can't force that off. That's not how MediaWiki's permissions system works, and if the extension is based off that bad assumption then it definitely won't go into svn cause that's the kind of thing that will only work if you hack MediaWiki to work that way, and hacks aren't supported.
I could have sworn that it worked in an earlier version of MW, but I see that setting
$wgGroupPermissions['student'] = false;
behaves just like you say it does. However, it was easy to whip up an extension to modify this behavior without hacking MW, by hooking at UserGetRights.
http://www.mediawiki.org/wiki/Extension:RestrictiveRights
Obviously, I wish that was the default - I think admins expect that if they explicitly turn something off in LocalSettings, it should not be overridden by something else. But that's just me.
Additionally, it's pointless to try and create an extension with a more limited way to manage permissions based off the Userrights stuff. Because if someone can use your form, then can just as easily access the build in Special:Userrights and edit permissions with what they are allowed to do. Restricting that within a extension's special page is pointless because all it gives you is a false sense of security that doesn't exist.
I'm not going to update the mediawiki.org page yet, since I figure it's likely that you will find other problems (unless you're sick of this and have given up!), but I have a test revision if you're willing to keep looking at these
http://trimer.tamu.edu/jh/UserRightsList.0.5a1.tgz
I created an global variable that can be set to allow users who do not have userrights to modify specific subsets of group membership of users they created. For my setup, I use:
$egUserRightsListChGrp['user'][] = 'student';
Inside the extension, I modify $wgAddGroups and $wgRemoveGroups based on $egUserRightsListChGrp, but since this is local to the extension, it does not affect access to Special:Userrights.
I also changed the date handling based on your suggestions, and did some other stuff to aid independence from mysql. But I don't have any installations to test those on.
I hope I'm getting closer to addressing your concerns.
JH
<snip>
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
mediawiki-l@lists.wikimedia.org