Hello ... I am wondering if there are any plans or discussions about enhanced the security of the wiki in a user/groups based, for example to let an editor protect his pages from view/modify other users that the ones he designate (with a special tag or something) ... I think that this is a feature not very useful at wikipedia sites, but yes on my wikis used mainly for projects development .
thanks, regards
On Thu, 21 Oct 2004 07:11:58 +0000, Victor Fariña wickle@gmail.com wrote:
Hello ... I am wondering if there are any plans or discussions about enhanced the security of the wiki in a user/groups based, for example to let an editor protect his pages from view/modify other users that the ones he designate (with a special tag or something) ... I think that this is a feature not very useful at wikipedia sites, but yes on my wikis used mainly for projects development .
Yes, a proper user-rights system is among the most requested features from non-wikimedia MediaWiki users, and there was recently some progress towards implementing it. I'm not sure how far it got, but certainly some code was checked in a few weeks ago based on the concept of assigning users to groups, and associating rights for different pages to different groups. You might want to glance through these threads in the mailing list archives:
* http://mail.wikimedia.org/pipermail/wikitech-l/2004-September/024982.html [quite old, fairly abstract discussion] * http://mail.wikipedia.org/pipermail/wikitech-l/2004-September/025594.html [the thread relating to the checked in user_groups code]
Hello again ... I am currently working on a simple extension to add security features on "per page" schema. Its functional but has very flaws of security, it works in all pages and an editor must/can create a tag like : <security> user=coff,admin groups=sysadmin </security> and the users listed are the only ones that can read the page . The extension info and download are on http://www.wickle.com/wikis/index.php/Security_extension
I would like why mediawiki developers are closed to new ideas based on security, i think this kind of extensions are great for the wiki community (although its not useful for wikipedia sites) I dont want a CMS, i dont want to change the wiki, I like mediawiki, but some answers at the IRC about this implementation are very frustrating, and other answers are greats .
regards
On Thu, 21 Oct 2004 15:18:48 +0100, Rowan Collins rowan.collins@gmail.com wrote:
On Thu, 21 Oct 2004 07:11:58 +0000, Victor Fariña wickle@gmail.com wrote:
Hello ... I am wondering if there are any plans or discussions about enhanced the security of the wiki in a user/groups based, for example to let an editor protect his pages from view/modify other users that the ones he designate (with a special tag or something) ... I think that this is a feature not very useful at wikipedia sites, but yes on my wikis used mainly for projects development .
Yes, a proper user-rights system is among the most requested features from non-wikimedia MediaWiki users, and there was recently some progress towards implementing it. I'm not sure how far it got, but certainly some code was checked in a few weeks ago based on the concept of assigning users to groups, and associating rights for different pages to different groups. You might want to glance through these threads in the mailing list archives:
[quite old, fairly abstract discussion]
[the thread relating to the checked in user_groups code]
-- Rowan Collins BSc [IMSoP]
On Oct 22, 2004, at 12:24 AM, Victor Fariña wrote:
I am currently working on a simple extension to add security features on "per page" schema. Its functional but has very flaws of security, it works in all pages and an editor must/can create a tag like :
<security> user=coff,admin groups=sysadmin </security> and the users listed are the only ones that can read the page . The extension info and download are on http://www.wickle.com/wikis/index.php/Security_extension
Well, the first problem I see is that it doesn't work -- anyone can simply click "edit" and remove the tags again. If it did work, then anyone with general edit permissions could lock any page to be inaccessible to other users just by putting in a random username/group, creating a denial of service attack vector.
I would like why mediawiki developers are closed to new ideas based on security, i think this kind of extensions are great for the wiki community (although its not useful for wikipedia sites) I dont want a CMS, i dont want to change the wiki, I like mediawiki, but some answers at the IRC about this implementation are very frustrating, and other answers are greats .
A parser extension is really the wrong place to be adding security hooks. It won't even get called in the places where it matters, and it's too easy to stuff in fake data or get around it.
You should probably be looking at Title::userCanEdit() and Title::userCanRead(), and the protect/unprotect functions. Currently these have a few hard-coded hacks instead of the general-purpose user group system that could be done but that there's been no sufficient interest in to write.
-- brion vibber (brion @ pobox.com)
Victor Fariña wrote:
Hello ... I am wondering if there are any plans or discussions about enhanced the security of the wiki in a user/groups based, for example to let an editor protect his pages from view/modify other users that the ones he designate (with a special tag or something) ... I think that this is a feature not very useful at wikipedia sites, but yes on my wikis used mainly for projects development .
thanks, regards
Hello,
I am currently implementing a new user rights management system. I just commited a simple showcase in cvs wich is not usefull at all :o)
The system is actually:
Create or edit a group Assign to each group some functions (reading page, moving page, read diffs, access to specific special page).
Then lookup and edit an user and assign him in some groups.
Simple example:
Built in groups: Anonymous LoggedIn L33t Admin
Wich have the following rights: Anonymous : Read, Edit, Diff, Special:RecentChanges, Special:Login LoggedIn : Read, Edit, Diff, Move, Special:RecentChanges, Special:Logout, L33t Admin : everything
One can build a bureaucrat group that only allow access to Special:MakeSysop.
Users can probably part of several groups.
The work is ongoing, users / groups can be edited and I am implementing the security layer that will query for permission and either allow access or deny it. I am not willing to commit anything until it's somehow working and that I have fixed some trivial bugs.
cheers,
On Fri, 22 Oct 2004 17:20:33 +0200, Ashar Voultoiz hashar@altern.org wrote:
I am currently implementing a new user rights management system. I just commited a simple showcase in cvs wich is not usefull at all :o)
The system is actually:
Create or edit a group Assign to each group some functions (reading page, moving page, read diffs, access to specific special page).
Then lookup and edit an user and assign him in some groups.
[...]
Users can probably part of several groups.
This sounds like a good, solid approach. One thing that might be worth considering (you may not want to code it fully straight away, but maybe bear it in mind while designing the architecture, so that it's feasible) is defining relationships between groups. e.g.:
* inheritance: Define permissions["Sysop"] = permissions["Logged in user"] + delete, undelete, protect, ... ** no need to explicitly change rights of all groups if you change the rights of a more general group; e.g. adding a globally usable Special: page shouldn't require changes to the permissions for group "Sysop" as well as group "Logged in user" ** another way of looking at this is: "Sysop" implies "Logged in user"
* cumulative: Define permissions["Sysop"] = delete, undelete, protect ** leave the wiki-organiser to assume that all users with "Sysop" status will also have "Logged in user" status in order to do the more mundane tasks ** this is the easier way to go, and is useful anyway for things like permissions["trusted SQL-savvy user"]="Special:AskSQL" which shouldn't imply any other rights, just be added to them
I hope this message isn't too waffly, and you get the general drift of what I'm on about. Like I say, these are mainly just eventual aims to keep in mind since you're essentially designing from scratch, rather than immediate to-do items.
Rowan Collins wrote:
Users can probably part of several groups.
This sounds like a good, solid approach. One thing that might be worth considering (you may not want to code it fully straight away, but maybe bear it in mind while designing the architecture, so that it's feasible) is defining relationships between groups. e.g.:
- inheritance: Define permissions["Sysop"] = permissions["Logged in
user"] + delete, undelete, protect, ... ** no need to explicitly change rights of all groups if you change the rights of a more general group; e.g. adding a globally usable Special: page shouldn't require changes to the permissions for group "Sysop" as well as group "Logged in user" ** another way of looking at this is: "Sysop" implies "Logged in user"
- cumulative: Define permissions["Sysop"] = delete, undelete, protect
** leave the wiki-organiser to assume that all users with "Sysop" status will also have "Logged in user" status in order to do the more mundane tasks ** this is the easier way to go, and is useful anyway for things like permissions["trusted SQL-savvy user"]="Special:AskSQL" which shouldn't imply any other rights, just be added to them
I hope this message isn't too waffly, and you get the general drift of what I'm on about. Like I say, these are mainly just eventual aims to keep in mind since you're essentially designing from scratch, rather than immediate to-do items.
Hello,
Actually each group need to be assigned every needed rights. There is nothing like inheritance / cumulation. So one have to:
Anonymous = permission(read) LoggedIn = permission(read, write) Sysop = permission(read, write, delete) Bureaucrat = permission(makesysop)
This way bureaucrat account is only to make sysop.
We want 1.4beta to be out by the end of the year and I personally would like to get the user right system in 1.4 (as it's a big new feature). As I am slowly coding it, I will try to keep it as simple as possible and then we can enhance it with inheritance later in 1.4.x versions .
cheers,
Actually each group need to be assigned every needed rights. There is nothing like inheritance / cumulation. So one have to:
Anonymous = permission(read) LoggedIn = permission(read, write) Sysop = permission(read, write, delete) Bureaucrat = permission(makesysop)
This way bureaucrat account is only to make sysop.
Actually, I think this is probably like my "cumulative" approach, I just didn't explain it very well; what I meant is that if a user is assigned to two groups, they will gain both sets of rights: * User:A has group "Sysop" -> permission(read, write, delete) * User:B has groups "Sysop", "Bureaucrat" -> permission(read, write, delete) + permission(makesysop) Or do you mean that a bureaucrat would actually need to log out and then log in with a different account which could make sysops but not edit pages?
By the way, any chance that while we're redesigning we can be consistent with terminology and get rid of this "An Administrator is someone with Sysop status" nonsense in favour of just calling the status flag "Admin"? [I know, this isn't as uncontroversial as I'm making out, it's just a personal bug-bear]
We want 1.4beta to be out by the end of the year and I personally would like to get the user right system in 1.4 (as it's a big new feature). As I am slowly coding it, I will try to keep it as simple as possible and then we can enhance it with inheritance later in 1.4.x versions .
Agreed.
Rowan Collins wrote:
Actually each group need to be assigned every needed rights. There is nothing like inheritance / cumulation. So one have to:
Anonymous = permission(read) LoggedIn = permission(read, write) Sysop = permission(read, write, delete) Bureaucrat = permission(makesysop)
This way bureaucrat account is only to make sysop.
Actually, I think this is probably like my "cumulative" approach, I just didn't explain it very well; what I meant is that if a user is assigned to two groups, they will gain both sets of rights:
- User:A has group "Sysop" -> permission(read, write, delete)
- User:B has groups "Sysop", "Bureaucrat" -> permission(read, write,
delete) + permission(makesysop)
Yup user are assigned to several groups then rights get ORed (so its cumulative).
Or do you mean that a bureaucrat would actually need to log out and then log in with a different account which could make sysops but not edit pages?
LoggedIn group is a build-in group so every users are assigned its permission. In the above example, Bureaucrat will be able to read and write. Rights for the Sysop group could just have been permission(delete).
By the way, any chance that while we're redesigning we can be consistent with terminology and get rid of this "An Administrator is someone with Sysop status" nonsense in favour of just calling the status flag "Admin"? [I know, this isn't as uncontroversial as I'm making out, it's just a personal bug-bear]
Actually my groups are:
Anonymous (read) LoggedIn (read, write) Sysops (read, write, move, delete) Bureaucrat (read, write, move, makesysop) LeetAdmin (everything you can imagine)
So sysops and bureaucrat are both childs of LoggedIn, still they are differents :o) As for the name, group names can be edited.
I believe there will be a lot of changes once the other developpers can have a look at it :o)
wikitech-l@lists.wikimedia.org