There are rare situations where a content managed website might function more as an organisations internal network or project management tool. In this case an extensive user account system works well and there are Drupal extensions that are built for this purpose, including the membership and event platform CiviCRM. A CRM is a more exclusive access system for members and staff, it might even work as an intranet or extranet.
Other situations that require an open or public sign-up system would be an eCommerce website or blogging platform perhaps. User accounts in this situation would have minimal access to the website’s editing tools. A blogger might need to create posts and manage comments for example. A shopper would only need to access their personal info and order history.
So there are a few instances where limited access roles are created in Drupal e.g. “Member”, “Moderator”, “Blogger” or “Customer”. The roles names are very generic which makes it easy when granting website permissions or actions to a large group of people.
Considerations before creating user roles:
- The highest level roles and permissions should only be granted for editors and developers.
- Use generic role names with limited permissions for public sign-ups, blogs or customers.
- Avoid creating high level accounts for staff who will never login to the website.
- Role names should describe which website tasks the person can do, not their job title.
- Create less roles and use generic names to create bigger user groups.
- If needing a wider members style network consider installing a CRM.
The journey from registration to access
1. Drupal account registration page
You need to think carefully before exposing Drupal’s account registration page for public sign-ups. The ideal situation is a shopping cart or for commenting on blog posts. There is only one registration form in Drupal and you should assign a single user role to everyone who creates account by this method and with very limited permissions.
If access is to allow the user to create content (e.g. a comment or post) then in this case the account should be approved by a human moderator. If it’s saving personal information for a product purchase or order tracking then this can be automated e.g. the user must confirm their email address is valid.
2. Account registration by invitation
For most situations user accounts should be created by an administrator or by invitation. Check the “Notify by email” option before saving a new account and the person receives an email with instructions to set their own password. A password must never be sent via email.
Assign an appropriate role for the new user that best describes what task they can perform on the website. So a website editor will be able to create, save or manage all the site’s content. The role name which is most ideal here would be “Editor” - you can have more editors, all with the same access permissions.
3. Does a website editor need Drupal training?
Consider the Drupal experience of a person before granting advanced permissions. Perhaps even design a set of user roles based on level of experience or provide training in some cases. Just as there are security risks from too much access by outsiders there might also be risks to the website’s stability if an inexperienced user, for example, deletes content by mistake.
4. Security risks when modifying Drupal’s core permissions module
In a few projects I’ve often been requested by a client to install additional modules to extend Drupal’s user permissions management, allowing finer grain control over access. For example access to very specific pages only. The more complex user access management becomes the higher the risk of a security breach through hacking.
I’d probably only recommend modifying or extending user functionality in Drupal if the website was hosted on a very secure server or is not a public website. Contributed extensions (or modules) just increase complexity and the risk of the website being hacked.
Designing a user management structure of well defined user roles is as important as any other aspect of Drupal development. Keep users in bigger groups and avoid additional modules for access that pose a security risk. Keep user management within the context of specific website tasks and activities or consider a separate CRM for membership or social frameworks.