== Authentication / Access Control Limitations ==
A given virtual host can only authenticate to one webiso server. Since club will never get into andrew webiso, andrew webiso can never take club passwords. Since andrew will never get into club webiso, club webiso can never take andrew passwords. So wiki.contrib.andrew will always authenticate to andrew webiso, and wiki.club.cc will always authenticate to club webiso.
All wikis are hosted on all vhosts, though http://wiki.club.cc.cmu.edu/ redirects to http://wiki.club.cc.cmu.edu/ccwiki (cclub wiki) and http://wiki.contrib.andrew.cmu.edu/ redirects to http://wiki.contrib.andrew.cmu.edu/wiki (contrib wiki). Right now styles/skins break across vhosts for other reasons, which we'll work on.
So in theory, andrew users can always have access to the cclub wiki, and cclub users can always have access to the contrib wiki (or any org wiki) by accessing the appropriate vhost. But this doesn't deal with the situation of a non-cclub alum or other affiliated (but not andrewid-holding) user wanting to authenticate.
The ultimate solution seems to be a higher-level scheme of our own design that wraps both webisos and a third database-backed user list for non-CMU users. When someone attempts to authenticate, we can present a screen (optionally bypassed if we know it's an andrew user or something) that lets them choose how they want to authenticate. We do the thing and then hand them our own cookie which is used from there.
This would take some effort, and the need doesn't seem to be extremely pressing just yet. Most of us seem to be OK with dealing with other issues first.
== Access Control ==
Our access control is based on an already mostly implemented "restrictions" feature, where a user must have a certain set of privileges to perform an action on an article. The privileges we are allowing to be used in restrictions are automatically granted by membership in a group. The current set of groups is 'sysop', 'officer', 'member', 'user', and '*' which give 'sysop', 'officer', 'member', 'user', and 'public' privileges respectively. Each of these groups also automatically has the privileges given to lower groups, so a user only really needs to be in one group. '*' is a builtin group that everyone is a member of, and everyone logged in is a member of 'user'. We are currently allowing only 'read' and 'edit' as restrictable actions, though anything, like 'move' and 'delete', could be restricted easily.
It is possible to give an action multiple privileges for restriction. Currently, that would require the user to have all the privileges, but it might be more useful for future group expansion if it would be satisfied with having at least one of the privileges.
Officers can use the 'restrict' tab at the top of an article to set the least privileges required to read and edit an article. There is a listbox for each action, so no need to have a long list of areas. It would be silly to let a group edit but not read an article, but it wouldn't break anything.
Proposed areas:
* ("Officer private area") Officers Read/Write, Others Deny
* ("Officer-controlled member area") Officers Read/Write, Members Read, Others Deny
* ("Officer-controlled campus area") Officers Read/Write, Members Read, Campus Read, Others Deny
* ("Officer-controlled public area") Officers Read/Write, Members Read, Campus Read, World Read
* ("Member private area") Officers Read/Write, Members Read/Write, Others Deny
* ("Member-controlled campus area") Officers Read/Write, Members Read/Write, Campus Read, Others Deny
* ("Member-controlled public area") Officers Read/Write, Members Read/Write, Campus Read, World Read
* ("Campus private area") Officers Read/Write, Members Read/Write, Campus Read/Write, Others Deny
* ("Campus-controlled public area") Officers Read/Write, Members Read/Write, Campus Read/Write, World Read
* ("Public area") Officers Read/Write, Members Read/Write, Campus Read/Write, World Read/Write
** This can, with some risk (mostly from spambots), temporarily solve the problem of getting alums write access
** Requiring world posts to be authenticated by reading a number out of an image wouldn't be unreasonable, and would stop spambots. That's actually an excellent idea, though it's a little more work for us. I'm pretty sure a library/module or two for captcha generation exists. Mediawiki patches already exist for this if we need it.
'''Please''' comment on or suggest better names for any of the above. Do we need any others? Is any redundant?
== Group Manipulation ==
We're using mediawiki's built in group system, so members of the 'officer' group (who automatically have 'userrights' privileges) can use the User Rights Management special page to add users to groups. However, this is tedious so we should have a mycontrib interface as well.
A special (immutable) group of orgtracker-recognized officers will exist. These people (through the mycontrib interface) will be able to populate the officers group. I'm thinking a big textarea into which they can paste andrewids, one per line.
To prevent abuse, a user with 'userrights' privileges can only exercise them on users in a less privileged group. So, sysops can add officers and members but not sysops, and officers may only add and remove members. No one can change their own privileges.
People in the officers group can (through mycontrib again?) (or through Special:Userrights) populate the 'member' group. Again, I'm thinking the textarea.
Logged in users are automatically in the 'user' group, and are given 'user' privileges. Anyone logged in using andrew webiso will be in this group automatically.
Everyone is part of the '*' group, which is given 'public' privileges.
== Article Manipulation ==
Anyone in the 'officer' group can change an article's restrictions, as well as move and delete articles. Knowing that we might one day expand the set of groups and/or allow organizations to create custom groups, should we generalize somehow on the criteria for being able to change the restrictions on a page?
Page creation requires edit privileges under the default restrictions. It would be possible to restrict it further, but I don't see any point.
When someone creates an article, one of the options below the big textarea will be a dropdown box with the access level. I'm thinking that it should list all access levels in which the creating user has write access. To encourage consistent access restriction across related articles, we might make it so that if a page is created by editing an empty page linked to from another page, the level preselected in the dropdown box is the same as the referring page.
Article creation and editing on the contrib wiki will be at access level "campus-controlled public" meaning that you have to be logged in to create or edit articles. An anonymous user will be given an error page if he tries to create or edit a page (and the edit tab is replaced by 'view source').
Org wikis will have a modifiable (by orgtracker-recognized officers, through mycontrib) default restriction, which also controls who can create articles. The default will be that campus users or higher can create articles, and the default access level applied to new articles will be "campus-controlled public." A warning about the level of publicity should be included in the edit template, along with a warning that setting the level to campus private or tighter isn't a true guarantee of security.
== Todo ==
* Mycontrib todos (mdille3)
** Improve session management to be cleaner and more modular
* Implement access restriction inheritance
** If someone clicks on a link on a page with ACL x, is sent to a create-this-page screen, and then creates the page, that page should inherit ACL x. (This shouldn't be that bad -- add a defaultacl thing to the URL linked to)
* It would be ''really'' nice if there was some way to "attach" files to a page.
** Could we add an "Attach file" link to the toolbox on the left (or maybe elsewhere?) which causes a standard file upload but appends an "Attached files" section if one doesn't exist? This could be special or just part of the wiki text. I can't find a patch anywhere that does this, but it seems like something that people might really appreciate if we contributed it.
* Find the diff representing our changes from original mediawiki sources
** And put a copy of our modified source in subversion for centralized versioning
* getskin/putskin.php
** Are we assuming tmpskindir exists? Are we leaving junk there?
** Don't use wikiskin/ -- use flat zips instead
* Attachment restriction
** The description page can be restricted (after upload), but anyone knowing the filename and the first two digits of the md5sum can get the file from the uploads directory.
** We should have a "create with restriction" option in the upload form (otherwise people will forget to set them)
** Combining this with an attachment concept or restriction inheritence (here, clicking "Upload file" from that page) is also a good idea
** Even restricted files will show up in the Files List special page -- is that OK, or do we want to hide ones that the current user wouldn't be able to read? We could remove the files list, but that'll result in lots of forgotten orphaned files.
* navlist.txt
** Move all navbar items to this (including main page, recent changes, etc.)
* Low priority
** Upload quotas don't seem to be getting enforced properly
*** Is JFS messing with us, or is something misconfigured?
== Old Todos ==
* Is 5mb of php being compiled for every request?
** Yes! Dealt with by using eAccelerator -- drastic speedup
* rlane: Enable LaTeX support (we're all geeks, c'mon!)
* rlane: When creating user, pull realname from andrew LDAP or password file (/afs/andrew/common/etc/passwd), but let them still change it if they want
* rlane: When creating a wiki, set the default (only) skin to be 'wikiskin' and have it contain our default template (for now, maybe monobook, but someday something nicer looking)
* rlane: Navbar - Read from a text file in the skin
* rlane: make uploads friendlier
** Can we have files "attached" to pages like in tikiwiki and others? No, link to them with Media:Filename.
** Can non-media files (i.e., xls, doc, etc.) be uploaded too? Yes.
*** How can we represent these? (i.e., can we use magic ('file') or extensions to pick icons?) MediaLinks extension is installed.
* mdille3: Enable uploads and upload quotas
** separate fs with group quotas enabled
** each org has upload dir, set +s to that org's magic gid
* rlane: Update wiki creation script (and posted-to version)
** Add yourself a user in the .htpasswd file in /admin for testing if you want
* rlane: Outline how the default access level works, how it can be changed, and tell mdille3 so he can add it to mycontrib
* Add default access restriction to ccwiki
* Get recent changes into new_wiki tarball
** And fix it... creating seems to leave empty LocalSettings.php?
* rlane: Create a script that generates (preferably on the fly, using some zip library for php) a downloadable zip of the layout (skin) for a given wiki
* rlane: Create a separate script that accepts a zip of the layout and overwrites the old one with that
** It's worth taking the time to get this right security-wise, but the emphasis should first be on getting something working
* Set the default ACL for a wiki
* Print access level somewhere on each page
* Mycontrib todos (mdille3)
** Create wikis
** Add checking of users added to groups against andrew