Difference between revisions of "CCGB Wiki Documentation"
m (tweaked a few words) |
|||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | == Logging In == | ||
| + | This Wiki uses the BX Weblogin system to authenticate users after clicking on the "Log In" link at the top (using a custom [http://github.com/phalenor/mw-auth_remote_user 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 == | == 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. | 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. | ||
| Line 6: | Line 9: | ||
== Access Control Lists == | == Access Control Lists == | ||
| − | + | === Overview === | |
ACLs are provided by the [http://github.com/phalenor/mw-acl/ MediaWiki ACL Extension], which is a custom extension written in-house specifically for this wiki, but generic enough to be used by other sites. | ACLs are provided by the [http://github.com/phalenor/mw-acl/ 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. | 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: | ||
| Line 62: | Line 67: | ||
=== How ACLs are combined === | === How ACLs are combined === | ||
| − | ACLs are combined as | + | ACLs are combined as follows: |
# ACLs from all Categories a page is a member of are combined | # ACLs from all Categories a page is a member of are combined | ||
# Negative ACL bits are evaluated | # Negative ACL bits are evaluated | ||
Latest revision as of 19:54, 18 July 2016
Contents
Logging In
This Wiki uses the BX Weblogin system to authenticate 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 follows:
- ACLs from all Categories a page is a member of are combined
- Negative ACL bits are evaluated
- ACLs from the NS:ACL page are combined with the current ACL set
- Negative ACL bits are evaluated
- ACLs from the current page are combined with the current ACL set
- 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.
