Users are people with login access to the website. They have a user name (login ID) and they prove their identity using a password. After the password has been validated, the login identity is remembered using a cookie. On every dynamic page view, this user identity is looked up, validated, and then used to grant access permissions to the website.
User accounts can be set up and managed using the Users & Groups module.
Once their password is validated, the user is remembered using a cookie. There are two methods:
auth.long_cookie_duration config setting).In either case, the user's browser (and possibly security firewall) will need to accept cookies from the website in order for logins to persist.
Users prove their identity using passwords. There are two mechanisms in place to ensure password security: password strength testing, and password encoding.
Password strength tests ensure that your password is not easily guessable. It does this by counting up the "good" characters in your password. Good characters are the ones that actually make the password stronger. Unusual characters (caps, numbers, punctuation) count for more. Repetition or obvious sequences count for less. Guessable strings like usernames or dictionary words also count less.
After counting up and weighing the quality of your password text, your password will get a score that will normally fall in the range 1-10, although it can be lower for weak passwords, and higher for very strong passwords. Examples for the sake of illustration:
| Password | Strength | Notes |
|---|---|---|
| password | -2 | 8 characters is okay, but dictionary words are weak |
| password0 | 0 | still very weak, but digit helps |
| passwerd0 | 0.5 | misspelling helps, but "pass" is still a dictionary word |
| Passwerd0 | 1.5 | capitalization helps |
| P4sswerd0 | 5.5 | fairly strong; has no dictionary words, but "wer" is sequential on QWERTY keyboards |
| pA55w0rd | 7 | strong; no dictionary words, no sequential characters |
| pA55-w0rd! | 11 | very strong; adding punctuation helps |
When setting a password, your password strength must be at least your user access level.
To raise or lower the strength requirements, set auth.base_pwd_strength (default is 5). Increasing it will require stronger passwords. Decreasing it will allow weaker passwords.
Password encoding determines how passwords are saved to the database. Several encoding schemes are supported, from strongest (recommended) to weakest:
Cleartext and reversible encryption can come in handy in certain development environments, but irreversible encryption is strongly recommended for production environments with active userbases. This helps to ensure that if your database is ever compromised, that actual passwords will not be leaked.
Once authenticated, users are granted access at a certain level. Access levels run from 0 to 9. Higher numbers imply a greater degree of privilege:
An executive is any person who can access the administrative control screens of your system - this requires an access level of 5 or more.
A visitor is any person who cannot access the administrator control screens of your system - this means their access level is 4 or less.
The difference between member, full member, and senior member (levels 2, 3, and 4) may not matter in your organization. You have the option of using these settings to distinguish between, and grant additional privileges to, certain membership categories, or to certain committees, to board members, or other higher-ranking users.
Note that membership management plug-ins will automatically move users up and down between user and member access levels when their memberships expire and get renewed. That is to say that expired members are functionally equivalent to level 1 users. They can still login to access user-only content, but they will not be able to access member-only content until they renew their membership to rstore that access level.
Every piece of content also has an access level, which runs on the same scale as above. It defaults to 0 (public) if not explicitly set. A user is permitted to view the content if the content's access level is less than or equal to the user's.
Note that public content (access level 0) can be published to flat files, which is much higher performance than restricted content, which requires validating the user's identity before deciding whether or not to serve the request. Restricted content (access level 1 or higher) is displayed dynamically, after authorizing the user.
If content is page-like (ie. it has its own link in menus or site maps), then attempting to access the content when you have insufficient access will return a login challenge. You must log in as someone with sufficient access to get past the login form.
If the content is a simple piece of content (such as an image or HTML snippet), it simply will not be displayed if you lack the access to view it. You can use this feature to turn pieces of content on or off depending on the level of the viewer.
Users can have a home site defined in their user record. If they have a home site, their access level applies only to content under that site. If they attempt to access a different site on the system, their access level will be ignored (treated as 0). If a user has no home site defined, they are considered to be a "universal user", and their access level applies to ALL sites on the system.
Roles are special permissions to modify content. The types of modifications you are allowed to do depends on the roles you have been assigned.
"Webmasters" will generally have editor, designer, and administrator roles, which allows them to do all of the maintenance tasks the CMS requires. Web designers may only have the designer role, if you want them to be able to update your look, but not alter the actual meaningful content. If you have junior staff who will be making updates, but want a more senior manager to approve all updates before they go live, then the junior staff should be given "editor" roles, and the senior staff should have "administrator" role.
Reviewer and owner roles are for the case where users contribute content, such as comments, profiles, and so on. The users who contributed the content are assigned ownership of their contributions, and those contributions are reviewed, moderated, or approved by a reviewer. If you have no reviewers, administrators will be used as backup reviewers.
Note that only executive-level users (level 5+) have access to the administrator control panels where these roles usually take effect. If you assign roles to regular visitor-level users (levels 4 and lower), those users might not have access to the control panels they need to perform those roles, unless you have made special effort to expose such functions on regular website pages.
Roles are assigned using content keys that "unlock" those permissions for the user. Keys tie a particular user to a particular piece of content, with a set of roles selected from above. The permissions apply to the selected piece of content, and all content within it in the site map. For example, permissions to manage a page will implicitly include all sub-menus of that page; permissions to manage a blog will extend to all articles posted into the blog.
Website administrators are typically set up as follows:
This will allow that user to add, delete, edit, and publish throughout the selected website.
You can include the designer role if the administrator understands principles of web design, HTML markup, and CSS. Leave it off otherwise, as careless content management of your design templates can break every page on your site at once.
You can also assign permissions to more selective areas of the website, simply by attaching the content key to more specific pieces of content. For example, the editor/author of a blog could be granted editor and administrator roles to their blog. Those permissions would extend only to the blog and its contents, but not to anywhere else in the site.
Keys to websites or sections can be issued from the Security module. Keys to more specific pieces of content can be issued using the keys tool in the workflow menu of the System Browser.
To revoke permissions, you can do one of the following:
If you have not been assigned any roles, your role is implicitly a "viewer" - allowed to see the content, but not change it. If you want to explicitly assign viewer keys, add the following configuration to your system
auth.view_keys = 1
Then a key with no roles will grant viewing permission to something the user is not otherwise permitted to view.
Example: to make a page viewable by one person only, set the page's access level to be executive level or higher so that regular website visitors cannot view it. Then assign a view key to the one user who should be allowed to see the page.
A group is a collection of users that can be treated as a single entity for security purposes. Content keys can be issued to a group, granting roles and permissions to everyone in the group without needing to issue individual keys to each one of them. Then you can simply add and remove people from the group, rather than manage all their permissions separately.
Groups are useful tools for handling security for:
The Users & Groups module allows you to build and manage your groups.
To grant permissions to a group, follow the same method for issuing content keys to an individual, but choose a group from the group options, rather than selecting an individual user.
A group resource is a public page or other destination on the front-end website that should be available to the group, but not to anyone outside the group. The general method for setting these up, is to:
You can use this method to set up pages, document libraries, chat groups (forums) or anything else that should be restricted to just that group. The Users & Groups module provides some simple tools for creating group resources that are keyed to a specific group.
Users retain their individual access levels when accessing something as part of a group. For example, if a piece of content has been set up as a group resource with an access level of 2, then only level 2 users in the group can access it. Any group members who are access level 1 will be denied access.