Sechan, Gabe wrote:
I'm using MediaWiki to create a corporate wiki,
and need to allow
access to certain pages only to certain groups. I don't see full
support for this in MediaWiki as of 1.4.11 (although there is stub
support- you can do this for moderators). Unless this has already
been implemented for 1.5 or there is already a 3rd party patch, I'm
going to implement this myself, and will be pushing for (and almost
will certainly get) permission to give this change back to the
community. While Wikipedia may not use it, it would be a nice
feature for the wiki in general. And if it brings in more corporate
users, those users may always contribute back more useful changes.
Use 1.5 for dev. 1.4 is no longer recieving real updates. I'll be
refering to the 1.5 schema in this e-mail.
By the sound of it, you are needing only per-page-per-group
restrictions. (As opposed to per namespace and/or per user.)
I also noticed there is not a list of permissions in this e-mail.
(Sometimes called actions in the code.) Do you have one?
This brings me to how to implement this. I have a few
ideas, if
anyone can comment on them.
Part 1- storing restrictions
I can either use the cur_restricted field of the cur table, or create
a new table that has a pair (pagename,group). If the pagename has
restrictions, you would need to be in one of those groups. If there
were no restrictions, it would default to open. Which of these ways
sounds preferable? I sort of like the new table, since then lookups
on old versions wouldn't need to access the cur table for
restrictions data.
Page/group/action (Actions requiring a certain group, stored per page)
are stored in the page_restrictions in the page table. It is parsed by
Title::loadRestrictions() and can be accessed by
Title::getRestrictions(). (It appears to operate on a strict system,
which you must be in the group to perform the action.)
Negative assertions (ie, saying a group may /not/ perform an action)
appears to be unsupported.
Part 2- storing groups
A new table with pairs (user id, groupname). A user can be in any
number of groups.
Already done: user_groups.
Part 3- applying restrictions
Any time someone tries to access cur_text, they need to check against
permissions. If they fail, they should not actually read the text.
Do only Article and EditPage need this protection, or will it need to
go elsewhere as well?
Per-page viewing is difficult due to templates and transclussion. You
basically have two opptions with that:
- Add some restriction checks to the parser
- Disallow inclussion from namespaces other than Template
I'm thinking of implementing this as a new class
(Permission) with a
two methods- checkPermission($user,$title) that will return TRUE if
user can access the title, and FALSE if not On a FALSE, the calling
code will need to push an error up the call stack in whatever way is
appropriate. Probably a web page saying that the page is protected,
and listing the groups.
Check current methods of the User, Article, and Title objects.
(User::isAllowed(), User::isAnon(), User::isBlocked(),
User::isBlockedFrom(), User::getGroupPermissions(), User::getGroups(),
User::getEffectiveGroups(), Article::protect(), Article::insertOn(),
Title::userCan(), Title::getRestrictions(), plus many others.)
If you want to implement per-namespace permissions, start hacking the
Namespace object.
The other function is groupList($title) that will
return the list of
groups with permission to read it. Its there to allow callers to get
allowed groups for the error page. (Alternatively, Permission could
generate an error page, but that sounds messy).
See the partial list of methods above. I think it's User::getGroups() or
User::getEffectiveGroups() is what you want. (Note that you should
instead pass a method a permission/action and a determinator (Title for
User, User for Title).)
Part 4- editing permissions
An extra box on the edit page, with a list of groups. Add a group to
add it to the restricted to list. You must have edit permissions (in
other words, you must be in one of the previously allowed groups or
be an admin/beauracrat) to add or remove a group.
Shouldn't this be a seperate page? Also, what about a global 'editperms'
permission?
Part 5- adding people to groups
Basicly, this is a special page. I'll probably allow, as a basic
method, any admin, beauracrat, or existing group member to add you to
a group. I'm not as interested in this part of the problem, as I'll
be getting my groups from /etc/group.
Special page is probably the way to go. Just make sure you have a
permission for it (so a user can't add themselves to the sysop group).
Any comments on how I plan to implement this? Or if
it already
exists and I'm being a moron (or missing a 3rd party patch
somewhere), please help me out.
One thing that's missing in the current system implemented in MW is that
there's no way to link a group with a global permission (w/o editting
LocalSettings.php).
-- Jamie
-------------------------------------------------------------------
http://endeavour.zapto.org/astro73/
Thank you to JosephM for inviting me to Gmail!
Have lots of invites. Gmail now has 2GB.