From what I've been reading, this seems possible, perhaps even without special patches. However, there also seem to be a plethora of different ways to go about this, and I'm wondering if the a "standard" way that is recommended. I'm running MW 1.6.3, and can upgrade if necessary.
What I'd like to do is create a "Public" namespace. This will be editable and mostly configurable to all logged in users. In addition, users will be able to edit most "talk" pages, including that from the main namespace.
Than Main namespace will be viewable by all (including *), but only edited/changed by an "Editors" group.
A "Privileged" group may be created. If so, it will have all of the abilities of the Editors group, plus the ability to view/edit a "Private" namespace, which none of the lower-level groups can even read. The basic intent is that new "official" pages will be developed here, and then moved into the main namespace when complete.
Finally, "sysop" will be able to do anything.
Here's the stuff I've put into LocalConfiguration to try to get things started:
/** * Additional namespaces. If the namespaces defined in Language.php and * Namespace.php are insufficient, you can create new ones here, for example, * to import Help files in other languages. * PLEASE NOTE: Once you delete a namespace, the pages in that namespace will * no longer be accessible. If you rename it, then you can access them through * the new namespace name. * * Custom namespaces should start at 100 to avoid conflicting with standard * namespaces, and should always follow the even/odd main/talk pattern. */ $wgExtraNamespaces = array(100 => "Public", 101 => "Public_Talk", 102 => "Privileged", 103 => "Privileged_Talk" );
My understanding is that this should create my new namespaces, there also seems to be a variable for creating "privileged" namespace, but I'm not sure the what is does differently, i.e. what the difference between a privileged namespace and a normal namespace.
I also read that new user groups are created directly in the DB, using SQL. I have no problems with this, though if someone knows of a simpler way, I wouldn't be averse to hearing about it :-)
The final step in this process is to assign rights based on namespace and group, not just on a group. I've come across these instructions: http://meta.wikimedia.org/wiki/Preventing_Access#Setting_permissions_for_a_G..., but was wondering if there's a better way of doing things. That seem kind of hacky, plus I'd guess it might need to be redone on upgrades of MW.
I have a few more questions:
1) Is there a way of saying that a particular group should take its rights from one or more other groups, and then modifying specific rights for itself? ("Rights inheritance", basically.) Alternatively, can a user be a member of more than one group, and if so, how are conflicting rights resolved? 2) Is there a convenient way of forbidding all rights to all groups, and then granting rights access as desirable to the given groups? I realize that the default rights configuration is largely the "correct" setting for a normal MW site, but I like the "all things forbidden unless allowed" since it makes for a very easy to configure website (you'll here about things that are disallowed but shouldn't be very quickly :-)) plus also maximized out of the box security. Currently my permissions settings look like this:
$wgGroupPermissions['*' ]['createaccount'] = true; $wgGroupPermissions['*' ]['read'] = true; $wgGroupPermissions['*' ]['edit'] = false; $wgGroupPermissions['*' ]['createpage'] = false; $wgGroupPermissions['*' ]['createtalk'] = false;
$wgGroupPermissions['user' ]['move'] = false; $wgGroupPermissions['user' ]['read'] = false; $wgGroupPermissions['user' ]['edit'] = false; $wgGroupPermissions['user' ]['createpage'] = false; $wgGroupPermissions['user' ]['createtalk'] = false; $wgGroupPermissions['user' ]['upload'] = false; $wgGroupPermissions['user' ]['reupload'] = false; $wgGroupPermissions['user' ]['reupload-shared'] = false; $wgGroupPermissions['user' ]['minoredit'] = false;
$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = false; $wgGroupPermissions['bot' ]['bot'] = true;
$wgGroupPermissions['bot' ]['autoconfirmed'] = true;
$wgGroupPermissions['sysop' ]['edit'] = true; $wgGroupPermissions['sysop']['createpage'] = true; $wgGroupPermissions['sysop']['createtalk'] = true; $wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop' ]['minoredit'] = true;
$wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop']['createaccount'] = true; $wgGroupPermissions['sysop']['delete'] = true; $wgGroupPermissions['sysop']['deletedhistory'] = true; // can view deleted history entries, but not see or r estore text $wgGroupPermissions['sysop']['editinterface'] = true; $wgGroupPermissions['sysop']['import'] = true; $wgGroupPermissions['sysop']['importupload'] = true; $wgGroupPermissions['sysop']['move'] = true; $wgGroupPermissions['sysop']['patrol'] = true; $wgGroupPermissions['sysop']['protect'] = true; $wgGroupPermissions['sysop']['rollback'] = true; $wgGroupPermissions['sysop']['upload'] = true; $wgGroupPermissions['sysop']['reupload'] = true; $wgGroupPermissions['sysop']['reupload-shared'] = true; $wgGroupPermissions['sysop']['unwatchedpages'] = true; $wgGroupPermissions['sysop']['autoconfirmed'] = true;
The main problem with this is that I'm not sure I've "shut down" all of the permissions I want to. Heck, I don't even fully understand some of the permissions yet :-)
As always, many, many thanks. Ken
Sorry about the top post ....
Personally, I would like to see them add an programmable authentication module. For example before editing or even displaying a page, it calls a function like is_authorized() which returns 1 or 0. By default the function returns 1. You can then add any code to check all sorts of security related issues.
regards,
jimmo
On Tuesday 13 June 2006 00:31, Ken McDonald wrote:
From what I've been reading, this seems possible, perhaps even without special patches. However, there also seem to be a plethora of different ways to go about this, and I'm wondering if the a "standard" way that is recommended. I'm running MW 1.6.3, and can upgrade if necessary.
What I'd like to do is create a "Public" namespace. This will be editable and mostly configurable to all logged in users. In addition, users will be able to edit most "talk" pages, including that from the main namespace.
Than Main namespace will be viewable by all (including *), but only edited/changed by an "Editors" group.
A "Privileged" group may be created. If so, it will have all of the abilities of the Editors group, plus the ability to view/edit a "Private" namespace, which none of the lower-level groups can even read. The basic intent is that new "official" pages will be developed here, and then moved into the main namespace when complete.
Finally, "sysop" will be able to do anything.
Here's the stuff I've put into LocalConfiguration to try to get things started:
/**
- Additional namespaces. If the namespaces defined in Language.php and
- Namespace.php are insufficient, you can create new ones here, for
example,
- to import Help files in other languages.
- PLEASE NOTE: Once you delete a namespace, the pages in that
namespace will
- no longer be accessible. If you rename it, then you can access them
through
- the new namespace name.
- Custom namespaces should start at 100 to avoid conflicting with standard
- namespaces, and should always follow the even/odd main/talk pattern.
*/ $wgExtraNamespaces = array(100 => "Public", 101 => "Public_Talk", 102 => "Privileged", 103 => "Privileged_Talk" );
My understanding is that this should create my new namespaces, there also seems to be a variable for creating "privileged" namespace, but I'm not sure the what is does differently, i.e. what the difference between a privileged namespace and a normal namespace.
I also read that new user groups are created directly in the DB, using SQL. I have no problems with this, though if someone knows of a simpler way, I wouldn't be averse to hearing about it :-)
The final step in this process is to assign rights based on namespace and group, not just on a group. I've come across these instructions: http://meta.wikimedia.org/wiki/Preventing_Access#Setting_permissions_for_a_ Group_on_a_whole_new_Namespace, but was wondering if there's a better way of doing things. That seem kind of hacky, plus I'd guess it might need to be redone on upgrades of MW.
I have a few more questions:
- Is there a way of saying that a particular group should take its
rights from one or more other groups, and then modifying specific rights for itself? ("Rights inheritance", basically.) Alternatively, can a user be a member of more than one group, and if so, how are conflicting rights resolved? 2) Is there a convenient way of forbidding all rights to all groups, and then granting rights access as desirable to the given groups? I realize that the default rights configuration is largely the "correct" setting for a normal MW site, but I like the "all things forbidden unless allowed" since it makes for a very easy to configure website (you'll here about things that are disallowed but shouldn't be very quickly :-)) plus also maximized out of the box security. Currently my permissions settings look like this:
$wgGroupPermissions['*' ]['createaccount'] = true; $wgGroupPermissions['*' ]['read'] = true; $wgGroupPermissions['*' ]['edit'] = false; $wgGroupPermissions['*' ]['createpage'] = false; $wgGroupPermissions['*' ]['createtalk'] = false;
$wgGroupPermissions['user' ]['move'] = false; $wgGroupPermissions['user' ]['read'] = false; $wgGroupPermissions['user' ]['edit'] = false; $wgGroupPermissions['user' ]['createpage'] = false; $wgGroupPermissions['user' ]['createtalk'] = false; $wgGroupPermissions['user' ]['upload'] = false; $wgGroupPermissions['user' ]['reupload'] = false; $wgGroupPermissions['user' ]['reupload-shared'] = false; $wgGroupPermissions['user' ]['minoredit'] = false;
$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = false; $wgGroupPermissions['bot' ]['bot'] = true;
$wgGroupPermissions['bot' ]['autoconfirmed'] = true;
$wgGroupPermissions['sysop' ]['edit'] = true; $wgGroupPermissions['sysop']['createpage'] = true; $wgGroupPermissions['sysop']['createtalk'] = true; $wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop' ]['minoredit'] = true;
$wgGroupPermissions['sysop']['block'] = true; $wgGroupPermissions['sysop']['createaccount'] = true; $wgGroupPermissions['sysop']['delete'] = true; $wgGroupPermissions['sysop']['deletedhistory'] = true; // can view deleted history entries, but not see or r estore text $wgGroupPermissions['sysop']['editinterface'] = true; $wgGroupPermissions['sysop']['import'] = true; $wgGroupPermissions['sysop']['importupload'] = true; $wgGroupPermissions['sysop']['move'] = true; $wgGroupPermissions['sysop']['patrol'] = true; $wgGroupPermissions['sysop']['protect'] = true; $wgGroupPermissions['sysop']['rollback'] = true; $wgGroupPermissions['sysop']['upload'] = true; $wgGroupPermissions['sysop']['reupload'] = true; $wgGroupPermissions['sysop']['reupload-shared'] = true; $wgGroupPermissions['sysop']['unwatchedpages'] = true; $wgGroupPermissions['sysop']['autoconfirmed'] = true;
The main problem with this is that I'm not sure I've "shut down" all of the permissions I want to. Heck, I don't even fully understand some of the permissions yet :-)
As always, many, many thanks. Ken
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
James Mohr wrote:
Sorry about the top post ....
Personally, I would like to see them add an programmable authentication module. For example before editing or even displaying a page, it calls a function like is_authorized() which returns 1 or 0. By default the function returns 1. You can then add any code to check all sorts of security related issues.
regards,
jimmo
I think this fucntion is already exist (for editing/moving/creating page), and is called Title::userCan (includes/Title.php). As far as I understand, you can hook it (or just edit it) and return false if it is not some public namespace or a talk namespace and the user doesn't have the necessary permission.
- -- #define Name RotemLiss #define Mail mailSTRUDELrotemlissDOTcom #define Site www.rotemliss.com
#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
On 14/06/06, Rotem Liss mail@rotemliss.com wrote:
I think this fucntion is already exist (for editing/moving/creating page), and is called Title::userCan (includes/Title.php). As far as I understand, you can hook it (or just edit it) and return false if it is not some public namespace or a talk namespace and the user doesn't have the necessary permission.
Let us assume that the user performing the following operation has no rights to "view" Secret:Page.
1. Open up a page the user can edit 2. {{Secret:Page}} 3. Save
Gasp. This is one example of the vast number of means of accessing content which makes attempting to use wiki software to lock down access a somewhat awkward process.
Rob Church
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rob Church wrote:
On 14/06/06, Rotem Liss mail@rotemliss.com wrote:
I think this fucntion is already exist (for editing/moving/creating page), and is called Title::userCan (includes/Title.php). As far as I understand, you can hook it (or just edit it) and return false if it is not some public namespace or a talk namespace and the user doesn't have the necessary permission.
Let us assume that the user performing the following operation has no rights to "view" Secret:Page.
- Open up a page the user can edit
- {{Secret:Page}}
- Save
Gasp. This is one example of the vast number of means of accessing content which makes attempting to use wiki software to lock down access a somewhat awkward process.
Rob Church
The site administrator can also prevent editing (for example, http://grants.wikimedia.org/), but it's not the solution for other wikis which have, for example, a private part (unviewable and uneditable) and a public part (viewable and editable).
Therefore, I suggest that the function Title::userCanRead will be called and checked when viewing a template, and if the user cannot view this page, an error message will be shown instead of the template.
- -- #define Name RotemLiss #define Mail mailSTRUDELrotemlissDOTcom #define Site www.rotemliss.com
#define KeyFingerPrint 4AFD 8579 A449 4267 BED9 38E5 6EF8 5B1F EBDE 7AC0
On 14/06/06, Rotem Liss mail@rotemliss.com wrote:
Therefore, I suggest that the function Title::userCanRead will be called and checked when viewing a template, and if the user cannot view this page, an error message will be shown instead of the template.
That'll kill caching.
Rob Church
On Wednesday 14 June 2006 15:11, Rob Church wrote:
On 14/06/06, Rotem Liss mail@rotemliss.com wrote:
Therefore, I suggest that the function Title::userCanRead will be called and checked when viewing a template, and if the user cannot view this page, an error message will be shown instead of the template.
That'll kill caching.
Rob Church
Convenience versus security. Any good admin is always aware of that trade off. I have two choices tonight:
- Go out to a movie with my wife and kids - Clean up the Wiki after someone trashed three dozen pages (or worse).
Hmmmm. Sounds like a no-brainer to me. ;-)
regards,
jimmo
On Wednesday 14 June 2006 12:33, Rotem Liss wrote:
James Mohr wrote:
Sorry about the top post ....
Personally, I would like to see them add an programmable authentication module. For example before editing or even displaying a page, it calls a function like is_authorized() which returns 1 or 0. By default the function returns 1. You can then add any code to check all sorts of security related issues.
regards,
jimmo
I think this fucntion is already exist (for editing/moving/creating page), and is called Title::userCan (includes/Title.php). As far as I understand, you can hook it (or just edit it) and return false if it is not some public namespace or a talk namespace and the user doesn't have the necessary permission.
Very cool! Thanks! I will definately have to take a look at it.
Regards,
jimmo
mediawiki-l@lists.wikimedia.org