Difference between revisions of "CCGB Wiki Documentation"

From CCGB
Jump to: navigation, search
Line 13: Line 13:
  
 
In general, ACLs are specified using the <acl></acl> tags within a page, category, or Namespace:ACL page.
 
In general, ACLs are specified using the <acl></acl> tags within a page, category, or Namespace:ACL page.
 +
 +
The second an ACL is involved, it overrides the base ACLs for the wiki (as specified in LocalSettings.php), meaning if you put an ACL on a page and you still want non-users to view it, you must specify at least '''* r'''.
  
 
ACLs are of the form:
 
ACLs are of the form:

Revision as of 15:11, 23 May 2010

Logging In

This Wiki uses the BX Weblogin system to authenticated users after clicking on the "Log In" link at the top (using a custom Auth_REMOTE_USER extension to MediaWiki). The URL presented for logged in versus not logged in users should be identical save for http versus https.

Request a Space

To request a custom Namespace (like BX or PhiX), contact admin-at-bx.psu.edu, and include the name of the namespace, and possibly a short alias for use when creating links to pages within that namespace.

Who Can View this Wiki?

Right now, the base permissions allow anyone to view, but only a member of the bxadmins group to make any changes. Access to any given page, category, or namespace is governed by the ACL (Access Control List) specified on that page, category, or Namespace:ACL page.

Access Control Lists

Overview

ACLs are provided by the MediaWiki ACL Extension, which is a custom extension written in-house specifically for this wiki, but generic enough to be used by other sites.

In general, ACLs are specified using the <acl></acl> tags within a page, category, or Namespace:ACL page.

The second an ACL is involved, it overrides the base ACLs for the wiki (as specified in LocalSettings.php), meaning if you put an ACL on a page and you still want non-users to view it, you must specify at least * r.

ACLs are of the form:

<acl>user bits, group bits, ...</acl>

The <acl></acl> tags can be specified multiple times within a given page and the contents will be combined.

entity->bit tuples are separated by a comma, with the entity->bit tuples delimited themselves by whitespace.

The bits are any of the following characters combined:

bit meaning
r read / view
h view page history
w watch a page
e edit
p protect
d delete
m move / rename
a all / administer

Certain bits imply other bits, for example, r also implies h and w.

ACLs may also contain negative bits by using the uppercase form of the bit. For example, if I wanted someone to be able to read and edit a page but not move or delete, I could specify <acl>someone reMD</acl>

Specifying Groups

This wiki integrates with the BX LDAP system, allowing BX LDAP groups to be used. Nothing special needs to be done to use a BX LDAP group other than listing the group name instead of a username.

There are also 2 meta groups which a user is a member of depending on which realm they are logged in as:

  • Penn State - meta-group name is psu
  • BX - meta-group name is bx

The anonymous group * can be specified to mean any user. The logged-in user group users can be specified to mean any user that has logged in.

Specifying Penn State or Friends of Penn State users

To specify a Penn State Access Account holder in an ACL, use the form username@dce.psu.edu

To specify a Friends of Penn State (FPS) user in an ACL, use the form fps_username@fops.psu.edu

These users may also be listed in a BX LDAP group.

How ACLs are combined

ACLs are combined as such:

  1. ACLs from all Categories a page is a member of are combined
  2. Negative ACL bits are evaluated
  3. ACLs from the NS:ACL page are combined with the current ACL set
  4. Negative ACL bits are evaluated
  5. ACLs from the current page are combined with the current ACL set
  6. Negative ACL bits are evaluated

This means that ACLs at the page level have the highest priority and can override any acls at the Namespace or Category level. Negative bits are evaluated at the level from which they came.

Also, for the case that a user is listed explicitly while at the same time groups are listed that the user is a member of, ACLs between all the groups the user is a member of are added up, negative bits are applied, then the ACLs for the user themselves are added. What this means is that if a ACLs that specify a user explicitly always have higher precedence than any ACLs on groups the user is a member of.