I work as a web developer, mostly working with Drupal and WordPress websites. I have worked with both platforms and built a number of customizations to them. Recently I have been hands on with Drupal 8 as I start porting some of the sites I maintain to the updated platform.
My recent projects have lead me to work with the security and content access layer in Drupal 8. As a content management environment focused around content and page items, the platform is designed with content at the focus. Which in many cases this is the correct and appropriate design road map. Sites that go above and beyond the target platform score, will run into issues and limitations in the platform from things as simple as entity access control, to complicated integrations with custom systems, and organization workflows.
The Core Problem
Drupal has one core problem in the platform. It was built around its Content Entity, or Node as it is called in code. WordPress users posts in the same way. Like in any other platform, this is the central idea of thing that will be managed, they are both CMSs after all. How it is used and extended within the platform varies, but in general they follow a few key design schematics on their base layers.
In the case of Drupal, the platform is designed around access and actions manipulating those content entities. An event booking platform, built with Drupal, would use content nodes for the events or tickets. A CRM would use nodes to represent clients, requests, and marketing teams. Everything is a node, or so they want you to think.
The platform leverages this architecture for a few reasons. Chiefly? Simplicity. Building access control around a single type of object or resource simplifies the development, developers don't have to worry about implementing complex access layers when building a module, and end users who simply want to build a site without touching the code base can use the built in interface to construct the type definitions and property field types. It is simple.
The Hurdles
I said the platform is simple, easy to use. Well it is, or at least until you look under the hood to tinker with the complexities of a platform. For a recent project, I was building out a knowledge base for a IT support group. The group has a tiered access control system with multiple silos, which between them had both shared and private content. A developer’s nightmare in terms of access control. Determining who could see what, when, and why was ninety percent of the development time.
In particular, one of the content types I built required having a base body, which itself represented an access controlled kb item. Beyond that, the item required having variants based on the silo and tier that the user (mostly employees) worked in. I chose to leverage the Paragraphs module, to provide the variants. This, and the alternatives (mainly the Field Collection module), left much to be desired in the way of access control. Thus we arrive at Paragraphs Access, a module completely of my own design.
The Paragraphs Access module was originally derived around Field Collections, which provides a more limited version of the Paragraphs features. The goal in both cases, was to add a layer on Paragraphs that would allow access control, through extendable means, to any Paragraph items on the site
Easy right?
We you get into the nuts and bolts of Drupal Core, access control on entities is straight forward. For 99% of entities, relying on permissions is enough for access control. If it is not content, it is probably configuration data or information that does not need access control. Module configuration, Search API servers, Webforms, Editor interfaces, and countless other entity types only need to be restricted to trusted users, designated by a permission which grants access to all instances of that type. Only content entities go beyond that to implement a more complicated access layer.
Node Access (The Basics)
The Drupal Node access layer is pretty simple (in concept). The core node module provides extendable functionality to allow other installed modules to specify content access requirements or provide users with access grants based on a set of rules. Taxonomy access determines access based on associated tags or categories. Role Access Control, one of my projects, does this based on roles assigned to a given item. Other modules provide similar features based on groups, users, events, or any other possible entity type. Over all this works well.
Duplicating It
For paragraphs, which by no means are content nodes, there is no access layer built in. Hence the need for Paragraphs Access. My goal was to implement the same functions as Node Access but for Paragraphs. Conceptually straightforward, but implementation had a few mountains to climb, and resulted in replacement and extension of some of the functionality provided by Paragraphs alone. I won't go into details here, maybe at a later point, but needless to say it took many days figuring out the right places to tweak and modify the base layer to ensure that access was properly checked, both when viewing and editing the items.
Isn't there a better idea?
I will first start by saying, that Drupal is a great and powerful platform. Over all, the project that I worked with is outside the mold of what it, or most CMS platforms are designed around. One hundred percent of the time, use the right tool for the job. In the case of the project I built, it probably was not. I used Drupal since the previous generation already did and there is no need to build from the ground up. After all of the work I did that got me thinking if there was a way that a platform could achieve access control at a higher level, and prevent this needless hacking.
This brings me to the last few months. A year ago, I started to develop from the ground up a content management environment of my own. I got far enough to conceptually think through most of the framework layer requirements. However, I stalled the project when thinking about addressing access control. With the thought that it needs to be baked in at layer zero, the database.
Database Layer Security
A platform needs to be secure. All entity types, for all users, any time of day. You can't have content leak between lines or broadly grant access rules. The way to handle this is to build a system of grants and requirements into the database, or ORM. The means that to the application, authenticated as a user, items that are denied access don't exist, or show as denied. This combined with low level concepts of users, roles, or permissions can make building an extensible access control layer through.
Should Drupal Change?
This question applies to Drupal, WordPress, Anchor, and any other CMS or application framework. And I would answer no. Those platforms server what they were designed for, and building (or rebuilding) it around a new service or platform would create more work for the developers, administrators and users, that is unneeded. They work, so don't ruin a good thing.
Then what?
What is next? My goal is to build a platform that handles security at a core layer. Implementing the above requirements, to provide and extensible and security focused framework or CMS. I at this point don't know exactly what the roadmap is, and there will be more details to come, so come back for more details.