Permissions


Introduction

The PostNuke permissions system allows complete control over which content on the site is available to different users, and what they can do with it. It also allows the site to have multiple administrators, each responsible for their own area, and further subdivides all content into separate realms to allow for multiple sets of content on the same site but viewable by different users.

This help file covers the administration of the permissions system.

Warning: Incorrect permissions could allow any user administrative access to your site. Please ensure that you have read and understood this document before attempting to set up your own permissions system.

Permission Attributes

Each permission is compsed of a number of attributes. These attributes are explained in detail below.

Realm

A realm is an area of control for content. Most users will not need this, as they will only have a single realm. More information on realms can be found in the realm manual.

User/Group

This is the user or group that the permission applies to. More information on groups can be found in the groups manual.

Component

This is the component that you wish the permission to work against. The component takes the form of a triplet separated by the colon (:) symbol. There are three types of component The component value is an anchored regular expression. To see a list of currently registered componenets you can click on the 'Component' or 'Instance' headings on the permissions view page.
Warning: Incorrect component values could allow any user administrative access to your site. Please ensure that you are familiar with regular expressions before attempting to set up your own permissions system.

Instance

This is the instance of the component that you wish to permission to work against. The instance takes the form of a triplet separated by the colon (:) symbol. The instance values are component-dependent; a list of instance templates for all currently installed modules and blocks is available by clicking on the 'Instance' heading on the table. The instance value is an anchored regular expression.

Level

This is the level of authorisation provided. It can be one of the following: Ensure that the correct level is chosen to allow only as many permissions as are required.

Ordering

Ordering of permissions is very important. When checking for permissions the authorisation system will return the first matching permission that it finds, and this must be taken in to account when setting up a permissions sequence.

User and Group Permissions

User permissions are considered to explicitly override group permissions. If a group and a user permission are both found for an authorisation attempt, the permissions system will return the user permission.

Examples

The following are a number of examples showing the security system, with explanations. All of the examples use group permissions rather than user permissions; they allow easier configuration for larger sites with multiple users. User permissions follow the same method, but are explicit

Initial Setup

Permissions example 01

This picture shows the initial permission settings that come with a new PostNuke install. A detailed explanation of each of the items follows:

Adding a Sub-administrator Group

Permissions example 02

This picture shows the permission settings after a new sub-administrator group has been added. The sub-administrator group is only allowed to administrate the 'Polls' and 'Web Links' areas of the site.

Note that the Web links area actually has two separate sub-sections for permissions. One is for categories, and the other is for the links themselves. We want this group to be able to work on both of these sub-sections.

This table only has one new entry. It is explained below.

Per-Group Settings

Permissions example 03

This picture shows the permission settings after a set of per-group settings have been added. Two new user groups, 'Technical people' and 'Design people', have been added and the administrator of the site wants to give them different polls that better reflect their knowledge.

This table has four new entries. They are explained below.

Note that any poll which does not explicitly fit the instance information is treated is ignored by these rules, so with this setup the normal poll will still show up in addition to the specialised polls.

Admin Overrides

Permissions example 04

This picture shows how to fix a potential problem that results from the above changes. When an administrator logs on, he will get beseiged by polls - the two specialised ones and also the normal poll. Being an administrator, he probably doesn't even want to vote in them!

The solution to this problem is to block the administrator from seeing the polls. An obvious first attempt to do this would involve setting up a permissions entry for the administrators with a component of 'Polls::', an instance of '.*', an an access level of 'None'. However, this is not what is required. An entry like this would block administrative ccess to the polls altogether, so the administrators could no edit current polls, create new polls, or even access poll results.

What the administrator really wants to do is not to block access to the polls themselves, but to block access to the polls blocks. This means that the polls blocks are not displayed, but the polls themselves are still fully available through the administrative interface.

Other Examples

Future examples will be made available at a later date.