What are authorizations for anyway?

TYPO3 is a powerful and highly configurable CMS. The possibilities that you have as a backend administrator are almost endless. However, not every BE user should be an administrator. Too many options bring too many dangers, such as deleting pages that should not actually be edited or when sensitive data in the backend is accessible to every editor. These are reasons for limiting authorizations. But of course a limitation can also be useful to simplify the daily use of TYPO3. The fewer modules, settings and functionalities you see, the clearer the backend will be. In this article, I want to give you a brief overview of the backend authorizations and show you a way to keep track of even complex authorization structures. I will use TYPO3 version 6.2 as a guide, as a list of all TYPO3 versions with all their differences would go beyond the scope of this article.

Law and order in TYPO3

As already mentioned, there are a huge number of authorization options for BE users. Due to the large number of different functionalities, the following is only a rough list of the possible settings for TYPO3 BE authorizations:

• Available modules (page, list, preview, file list, etc.)

• Access to tables (view/edit data records)

• Available page types (pages, links, folders, etc)

• Visible fields from page content (tt_content, tables from extensions, etc.)

• Restriction of available plugins (TYPO3, extensions, etc.)

• Restriction to the available language

• Workspaces

• Database shares (page tree)

• Directory shares (Fileadmin)

• Rights for file operations (read, write, move, delete, etc.)

• available categories

• Restriction to domain

• TSConfig (e.g. hide tabs, set default values, etc.)

And because the visibility of the page tree can of course also be restricted, there is also the access module with which you can set the following authorizations:

• Show page

• Edit content

• Edit page

• Delete page

• Create new pages

• (+ everything on all subpages)

These authorizations are set to BE groups. More on this later.

Class instead of mass

With many different BE user profiles, that's a lot of setting options. To avoid losing the overview here or having to create a separate group for each user, it is advisable to separate the groups logically and group them again . We differentiate between the following types:

Name- Configuration used Purpose
Scheme

The naming scheme is always "[KURZEL_DER_BERECHTIGUNGSART] speaking group name".

Advantages

• The respective groups only contain the corresponding authorizations

• The groups are named "speaking"

• Filtering by authorizations is easy based on the name (e.g. via the database or the TYPO3 backend search for all language groups → "[L]")

• A user only ever receives one META group

• Assigning a group to a user in the backend is clear, as the list of available groups is alphabetical (and therefore categorized)

Disadvantage

• This can result in a large number of groups for complex projects

A (somewhat larger) practical example

Let's assume we have a new TYPO3 site and the customer has made the following request with regard to BE users:

Based on this requirement, I would define the groups as follows:

Basically, three main groups are required: one group for page design ("Editorial"), one for news design ("News") and one for the newsletter ("Newsletter"). The page and news design is divided into admins and editors. As the admins have slightly more authorizations than the editors, we need several different groups. If we now compare the editorial groups "[META] Editorial admin" and "[META] Editorial", we notice that the admin group has the same DBM and FM group as the editorial group. As both need to access the same data records (DBM) and files (FM), it does not make sense to create different DBM/FM groups here. The ACL and P groups are different because we do not grant the normal editorial group authorization to create pages (P group) and plugins (ACL group). This is reserved for the "Editorial admin" group. The same applies when comparing the news groups "News Admin" and "News Editorial". The "[TS] Admin" group is a generic group that allows the recursive deletion of pages via TSConfig. A useful setting that is only allowed for the admin groups in this example.

The "[META] Newsletter-Admin" group could of course receive the "[DBM] News" and "[FM] News" group. However, in this example I have decided to explicitly use new groups, as this is a different type of user. In the event that further editorial groups are added, this could lead to further adjustments to the newsletter admin. In my opinion, a clear separation according to functionality makes sense here. In addition, an EXT group for DirectMail is used to release the backend modules of the extension. As limited access to DirectMail modules makes less sense, different access authorizations for the extension are probably not necessary. In addition, the EXT group offers the advantage that the authorizations for DirectMail are more likely to be searched for in this group than under the ACL group, which may have far more different configurations activated/deactivated. It is therefore clearer and easier to handle.

If we now want to know which authorizations user XYZ has, we can roughly find this out via the assigned META group. The more descriptive the group names are, the more practical they are. On the other hand, a name that is too precise, such as "[ACL] News categories (PHP, JS, HTML, CSS)", can provide incorrect information immediately after a change, e.g. if a new news category has been added but the name of the group has not been adjusted.

Let's assume that a few months have now passed and the first adjustments to the BE authorizations have been made:

As we have given the newsletter admin its own groups for news access authorization, all other groups remain unaffected by these adjustments. The groups "[P] Newsletter-Admin" and "[ACL] Newsletter-Admin" will be adjusted to grant read-only access to the news.

We therefore need a new group for managing the internal news with access to the existing regular news. The group could be structured as follows:

• [META] News-Intern-Admin

  • [ACL] News-Admin

  • [DBM] News-Intern

  • [DBM] News

  • [FM] News

  • [P] News-Admin

  • [P] News-Intern-Admin

  • [TS] Admin

We use the same groups as the "News-Admin" group and extend these with our own DBM and P groups, as access to the file mount and page tree is required for the internal news. Of course, you could also define the "[META] News-Admin" group as a subgroup. But this has the disadvantage that you have to check the subgroup of a subgroup when making adjustments. Furthermore, the "[META] News-Admin" group could receive changed rights due to another request, which would then also affect this group. You should be able to assume that changes to a META group have no effect on other META groups. This could be seen as a kind of convention.

The previous permissions only had "allow" settings. For this reason, an additional "ACL-DISALLOW" group is now used, which prohibits permissions on content elements: the "[ACL][DISALLOW] All plugins and special page content" group. This group is now given to the META groups "[META] Editorial" and "[META] News Editorial". This means that the corresponding users only have access to the content elements/plugins that are not prohibited.

If we now release this plugin in the ACL-DISALLOW group, the "News editors" group would also have access. As this is not desired, we now need more "ACL-DISALLOW" groups:

• [META] Editorial
  

  • [ACL][DISALLOW] Everything except text, images and ExtList plugin

  • ...

• [META] News editorial office

  • [ACL][DISALLOW] Everything except text and images

  • ...

Of course, the groups only differ by a tick in the ExtList plugin, but as the "once forbidden always forbidden" principle applies here, I would go down the aforementioned route. Especially when it comes to blocks such as content elements or plugins, it can make sense to outsource them to different groups in order to be able to name the group appropriately and to get an overview of what is prohibited by the group without having to edit the group directly. Depending on the size of the project and the extensions installed, the list of content elements and plugins can quickly become very confusing.

The requirement has a major impact on our BE authorization. And there are several ways to implement this requirement:

1. Option:
We create the language groups "[L] German" and "[L] English". We then rename the META groups and add a "(DE)" to the name, e.g. "[META] News-Admin (DE)". We then copy the META groups and change the DE to EN. Now the respective META groups must be extended by the respective L group, depending on whether DE or EN.

2. Option:
The META groups remain unchanged and the respective BE users receive the L group for their language.

The second option has the advantage that the number of groups does not increase too much and remains manageable. However, this contradicts the readability of the META groups. The information about which language the BE user is allowed to edit is therefore contained in the user himself and not in the group. My decision here would very much depend on whether there are plans to offer even more languages. There will never be a perfect solution, as it always depends on the ACTUAL and TARGET status of the project.

Conclusion

A good and sensible structuring of the BE authorizations in TYPO3 makes it easy to keep track of and expand them. The administration of BE authorizations is not an easy task for larger projects, but with the necessary discipline and structure it does not have to become an unruly juggernaut.

A look into the future

Anyone who operates a CI/CD infrastructure and repeatedly makes adjustments to BE authorizations will quickly become annoyed. Different database inventories prevent the groups from being exported to the target system and so the changes have to be documented and manually transferred to the respective target system. Even developers and integrators are only human and can make mistakes. Especially when you have to trawl through hundreds of checkbox lists to tick the one box that meets the customer's requirements. This will soon be a thing of the past! The TYPO3 developers are working on making it possible to outsource user authorizations to files. The advantage of this is obvious: versionable BE authorizations. This is perfect for a CI/CD infrastructure and if the configuration files for the user authorizations are also easy to read (perhaps a clear YAML file?), the documentation for the authorizations (which is outdated again at the latest after writing) is also no longer necessary.

P.S.: And thanks to Daniela Grammlich for sketching the cover picture. If you want to see more sketchnotes, go here: https://grammheimlich.de/