Users and Permissions¶

User management is a very important aspect of your XMM installation. The Admin provides ways to deal with authentication and authorization.

Users¶

Listing and modifying existing users can be done via the interface found on ‘Administration’ -> ‘Users’. Creating users can also be done using the corresponding button on this page.

The listing will show a table of users, containing the login, names and email addresses of all users. Additionally, you see a user’s primary role, last login and status at a quick glance.

Creating a user¶

A new user may be created at any time, fill out the provided form and, if the “active” checkbox was selected, the new user will be able to login immediately.

Editing a user¶

Editing a user is straightforward. However, it is not possible to see a user’s password, as passwords are only stored as hashes in the database. To edit a user’s password, click on the “Edit” link above the password field and overwrite the field’s value.

Groups¶

Groups control what users have access to which part of the XMM. One user may have one or more groups assigned to them, each consisting of permissions that are combined if multiple groups are present. Multiple groups will never cancel out each others’ permissions.

Permissions¶

Permissions follow a consistent naming scheme, starting with the broadest access definition and providing more fine grained control with each successive lower sub-permission.

For example, the permission “Collections” grants full access to every part in the collections menu as well as containing date. Whereas “Collections :: ETIM” will only grant permissions on the “ETIM” collection node, while others will be invisible.

A user may have the “is_superuser” flag set, this automatically grants every permission without explicitly setting it.

Most permissions are fixed in the system, however, there are a few dynamically generated permission definitions which updated automatically by the system. These include fine grained control over individual root nodes in your tree structures, i.e. collections, media and CMS. Granting and revoking permissions is done by assigning one or more permissions to individual users and roles.

The format follows the format Category< :: .Subcategory [ :: Action]>. It can handle one or more sub categories as well as an optional :: Action suffix. If the :: Action suffix is used, only this action is allowed, otherwise all actions on the resource are presumed.

If a user is granted permission to one level, each sub-level is automatically accessible as well.

Example: User A has the permission Masterdata :: MyModel :: Read. This will allow user A to see all MyModel s in the masterdata tab but prevent access to any other model or modification of any dataset.

Permission levels¶

Internally, permissions use a keyword instead of a more user-readable representation. These shall be used from here on out. The primary access groups are divided as follows:

module.admin
The primary “Administration” panel.
- system_model
- system_modelgroup
- system_nodetype
- system_attribute
- system_pagetype
- system_blocktype
- system_user
  Even without permission, every user has the permission to modify their own user.
  
  Note
  
  Not implemented yet.
- system_userrole
  Includes granting and revoking permissions.
- system_task
- system_taskexecution
  Task executions / history. Write permission allows starting tasks, since starting a Task creates new executions.
- units
module.masterdata
The masterdata tab to manage all model instances as defined in the admin panel.
- <model_key>
  Each model has a unique key identifier which is used to determine access to these model instances in the masterdata tables.
module.collections
Collection management for classifications and other structures.
- <root_id>
  Allows access to specific root nodes in collections. Each root node ID can be configured individually. It is not intended to further restrict access after root nodes 1.
  
  Note
  
  Not implemented yet.
- collection_node
  Generic permission for all collection nodes.
module.cms
Pages for use on a website.
- <root_id>
  Same functionality as collections.<root_id> 1.
  
  Note
  
  Not implemented yet.
- cms_page
  Generic permission for all CMS pages.
module.media
Files and folders management.
- <root_id>
  Same functionality as collections.<root_id> 1.
  
  Note
  
  Not implemented yet.
- media_file
  Generic permission for all media files.

For ease of use, granting a higher-level permission to a user or group will automatically grant all sub-permissions. This makes checking for permissions later a lot easier and more straight forward, as no calculations have to be done when checking access, which happens more often than modifying permissions.

So granting the module.admin.system_unit permission will grant all actions on the Unit model.

1(1,2,3): In case a root node is moved below another level, permissions will be reset.

Access restrictions¶

Users may be presented with a limited interface according to their privileges. The XMM UI should perform simple checks wether to display a link or node of a certain types, as per defined permissions.

Should a user land on a page where they do not have access to, the front end may not perform any checks, as the backend server will perform these upon requesting the resource and respond with a HTTP 401 in case a higher permission is required (e.g. when trying to read an item that they do not have access to or when writing without write permission).

API access tokens¶

Users can hold access tokens, which can be used to access the API (using http basic auth). The token “holds” the same permissions as the user.

To generate such a token on a user, go to the CLI, in the project folder and run ./manage.py create_api_key. You will be asked to enter either e-mail or login-nickname of the user. As output, you should get instructions how to use the API key with the Python requests library:

from requests.auth import HTTPBasicAuth
import requests
requests.get('http://localhost:8100/api/cms/page/SOME_PUPLISHED_PAGEID/', auth=HTTPBasicAuth('', 'APIKEY'))