Using MediaWiki at CSE

The Wiki Concept

The key idea of a wiki is that users can use a web browser to both read and create content. Content creation is performed using a special simplified markup language that is intended to be both simpler than and more limited than HTML. In its purest form, a wiki can be accessed or edited by anybody, which makes it a popular tool for collaborative creation of web content.

The unit of publication of a wiki is, as with HTML, the page. Pages can link to other pages both within or external to the wiki, and may permit images and attachments. There is typically no hierarchy to the pages. Pages spring into existence as they are defined.

There are dozens or hundreds of implementations of the wiki concept, commercial and open source, of which the MediaWiki package discussed in this document is but one.

About the Software

In broad outline, MediaWiki is a PHP application that is designed to work with Apache httpd. It uses MySQL as its data store, and will use a small number of other software packages to provide optional features such as image manipulation or the ability to enter mathamatical formulas.

There is also a facility for plugging in external modules— called extensions— that, like MediaWiki itself, are coded in PHP. Here are some examples:

SpamBlackList

Allows IP addresses or ranges to be restricted from accessing the wiki for content spam control purposes. Documented here.

Auth_remoteuser

Allows apache-level auth mechanisms such as Basic Auth, CSEcookie, and pubcookie to replace the application-level auth. Documented here.

Cite

Provides support for citations (footnotes), documented here.

WikiWidgets

Embed a wide variety of external services such as Google Maps, Google Calendar, or Twitter. Documented here.

There is also support for rendering mathamatical formulas which is not formally an extension but which requires both extra installation/upgrade steps and certain extra system software. It is therefore not enabled by default.

At this September 2013 writing, we are running versions 1.20 and 1.21 of MediaWiki. Major releases are (in theory) made quarterly (but more rarely in practice). Because MediaWiki is the object of frequent security alerts, staff tends to update installs we support to the latest version as soon after its release as is practical. (Running your own install at CSE? Please also keep it updated.)

Anybody that can create content on a PHP-enabled Apache web server and that has write access to a MySQL, SQLite, or PostgreSQL database can install and run MediaWiki without staff support. For example, all members of the CSE community have accounts and web areas on abstract.cs, which runs both a PHP-enabled Apache httpd and a MySQL server on which accounts are available upon request. But this document is designed for those who have chosen to have staff install and administer MediaWiki.

Authentication and Roles

MediaWiki has application-level authentication and a small set of defined roles, but much of what those mean operationally is a matter of configured policy, described below. Policy is set in the configuration file LocalSettings.php.

"Application-level authentication" means that users may choose to register a username and password and to use those credentials to log in. A typical (but not the default) policy would be to restrict page edits to logged-in users. There is no facility for defining which set of regular users can edit particular pages, however. It is also possible to specify which specific pages can be read by an anonymous user.

Local policy may (but does not by default) require that accounts must be created by an administrator. By combining that policy with policy that requires users to be logged in to perform edits, you can control who can edit content in the wiki.

A key defined role is that of the SysOp, of which there is always at least one. A SysOp can perform such actions as deleting and undeleting pages, editing "protected pages," and, if policy requires registration approval, approvng registrations.

A Bureaucrat is a SysOp that is privileged to grant other users SysOp status.

"Protected pages" are quite simply pages that have been marked by a SysOp to be editable only by another SysOp.

External authentication of any kind supported by Apache httpd can be applied to any install of MediaWiki in order to provide course-grained access control. There are two ways to use external auth:

independently from application auth

Visitors who authenticate to the external auth scheme will be anonymous to MediaWiki. Depending upon policy, first-time users may be able to register themselves with a username of their own choosing, returning visitors may be able to log in to their MediaWiki accounts, and visitors may be able to remain anonymous.

integrated with application auth

The "Auth_remoteuser" extension is used to auto-register new users and auto-login returning users. For example, if you use CSEcookie external authentication, a MediaWiki account will be created for first-time visitors using the CSE username that they used to authenticate. Returning visitors will be identified and logged-in to their existing MediaWiki accounts. Note that there are no anonymous users in this case.

Note that the identity of a user who so authenticates is not used by MediaWiki, so even in the event that a username-based external authentication mechanism is employed, users will still need to authenticate directly to MediaWiki for their MediaWiki identity to be known and used.

Problems and Pitfalls

The chief problems with wikis are defacement— mindless vandalism of content— and content spam— decorating a wiki with links to low-life commercial sites in order to leverage the PageRank of the wiki to increase the PageRank of the linked sites.

To mitigate, countermeasures are introduced to restrict access.

Policy Decisions

Below is a list of the questions that need to be answered before a new MediaWiki install can be set up.

What is the mission of the wiki?

That mission will determine where the wiki is hosted (and whether staff can support it).

What will the name be?

The basic URL of a wiki is of the form http://<hostname>/<wikiname>, where <wikiname> is a single mixed-case word.. There is also a (possibly multi-word) name that is used in the HTML title of the wiki pages.

Who will be the contact?

An email address is needed as a contact.

What will be the credentials for the initial SysOp and Bureaucrat?

Every mediawiki install has an initial SysOp/Bureaucrat administrative user that can perform actions such as creating user accounts and annointing other SysOps. (This is true even of the policies of the wiki are wide open, allowing users to self-register.) The credentials of that user consist of a username and a password.

Will I allow uploads?

By default, users may not upload any files, including images. You may wish to allow it.

What file types may be uploaded?

Even if file uploads are permitted, the default policy permits only files with filename extensions corresponding to common image types (gif, jpg, jpeg, png) to be uploaded. You may wish to allow other filetypes such as pdf or Microsoft Word formats.

What external access restrictions, if any, will be applied?

If you know that all of your collaborators have CSE accounts, you can restrict access via the CSEcookie mechanism. If that isn't true but all have UW accounts, Pubcookie can be used. In either event, you can restrict access to either any account holder or to selected account holders.

Basic auth allows you to create your own usernames and passwords and can be a good choice when you have outside collaborators. Using Basic auth with trivial credentials— exposed in the authentication challenge itself— is a cheap way to halt robotic content spam.

Will users be required to perform an application-level login in order to read content?

You may specify that only users that have logged in to the wiki may read other than the top-level and login pages. This might be appropriate if your wiki contains sensitive content that you do not wish to expose to every user that can get past whatever external authentication measures you have established.

Will users be required to login to edit content?

You may specify that users can read but not edit content without performing an application-level login. This policy is appropriate when your content is not sensitive but you cannot trust all users that are able to get past whatever external authentication measures you have in place.

Will users be permitted to self-register?

If you allow users to register themselves but require that users log in to edit content, then any user that can get to the wiki can perform edits. If that's not what you want, then you will need to specify that only a SysOp can create wiki accounts for your users.

What, if any, extensions are sought?

See the section above for a brief list of MediaWiki extensions that are in use at CSE.

MediaWiki Installs at CSE

The table below lists only a few of the staff-administered installs of MediaWiki along with information about their mission and the established policies.

In general, web content with an instructional focus is hosted on cubist.cs.washington.edu, while those with a research focus are hosted on dada.cs.washington.edu (AKA www2). Keunwoo LeePaul PhamJacob Nelson's Public MediaWiki is hosted on abstract.cs.washington.edu, where some users are also running their own installs. Several research projects with their own Apache-with-PHP servers host their mediawiki installs on those servers; for example, Urbansim hosts four on oslo.cs/urbansim.org.

Name	Purpose	Contact	Policy
Public	Free-for all discussion of any topic.	Jacob Nelson	No external access control. Requires assisted registration/login to edit pages. Uses SpamBlackList module for defacement control.
GRAIL	Graphics research.	Stephen Spencer	Requires SysOp to create account. Requires login to edit pages.
Instructional	Persistant, collaborative course content.	S. Morris Rose	Pubcookie (external) authentication.
Research	Used by a variety of research groups that don't mind sharing an install with other groups.	S. Morris Rose	UWNetID/pubcookie (external) authentication.
CSEP590TU	Topic: Information Technology & Public Policy	Ed Lazowska	Legacy content. Required application-level login to edit pages.
cse143-admin	CSE143 course administration	Travis Kriplean	Auth_remoteuser/CSEcookie auth: membership in cse143 "web group" required to access, with auto-login and auto-registration.
CyberSecurity	CSEP590TU, Autumn 2005. Topic: CyberSecurity	Ed Lazowska	Legacy content; all editing disabled.

Tips 'n' Tricks

This section could profit from some user input. Send your suggestions here. Yes, we are aware of the irony of not using MediaWiki to collect this content.

spell checking

There is a MediaWiki extension for spell checking, but we don't use it here because there are other good solutions. Users of Firefox 2.0+ have spell-checking in HTML forms integrated into the browser. Users of Internet Explorer can add spell-checking using the cost-free ieSpell browser extension.

editing

Some folks (me amongst) find editing in a textarea to be painful. Firefox users can invoke the editor of their choice upon demand using the It's All Text! browser extension; Chrome users can do the same with the (misleadingly-named) Edit with Emacs extension. Many more approaches are documented in Wikipedia:Text editor support.

creating accounts

If you are charged with maintaining the accounts in a mediawik– probably because account self-creation is forbidden– you may find the process of creating a new account to be obscure. Here's how you do it:

1. Click on Special Pages in the left navigation
2. Click on Login / create account
3. Click on Create an account
4. Fill in the form with the user's username, password, email address, and fullname, then submit the form

In order to create accounts, you must be a "sysop" for the wiki— if the link at step two reads "Log in" instead of "Log in / create account," you are not a sysop. The section on "managing roles," below, explains how a sysop can create new sysops.

managing roles

If you are a sysop, you can manage user roles using the links in "Users and roles" section of the Special Pages page. Typically, you would use this facility to give an existing user sysop privileges so that they can help administer the wiki by performing operations such as creating user accounts. Click on "User rights management," enter the username and submit the form, then check the "administrator" and "bureaucrat" checkboxes before submitting the form again.