DEV Community

Strapi for Strapi

Posted on

Why we split the management of Admin Users and End Users

Recently, we merged a pivotal change to how we treat Admin Users and End Users. This post will describe what we did, why we did it and how it affects you as you continue to develop your projects going forward with Strapi.

With the release of the Beta Version of Strapi, Admin Users (also called Administrators) and Users (called Users or End Users) are separated. Admin Users primarily interact with the Strapi dashboard. End Users primarily consume the API or access the front-end.

We made this split to maintain a separation of concerns going forward. Both Admin Users and End Users fulfill a different set of features:

For example, Admin Users concern themselves with content contribution (creating and editing content, moderating, translation, publication, A/B testing, previewing content prior to release, etc.), Strapi Administration (API tokens, webhooks, API testing and status checks, logging/monitoring, statistics, etc.) and a last example, third party providers (OAuth, LDAP, SAML).

These Admin User features are distinct and separate from the features available for the End User.

The features for the End User revolve around an authentication and authorization layer that you can build your business logic on top of. Similar to the features we are developing for the Admin User, we have goals we want to achieve with the users-permissions plugin. For example, providing a fully featured authentication and authorization service with OAuth2 and OpenID Connect, providing an advanced Role and Permissions system, custom policies, managing 3rd party connectors like Facebook and Google.

Of note, by separating the Admin User and End User, we have made it possible to create a logical integration where Admin Users become End Users. This also applies where an End User becomes an Admin User. Granular control will now be possible.

The separation of the Admin User and End User occurs at the database level and the UI level. Admin Users now occupy an administration panel located under, “Manage the administrators”, found under the username.

End Users are still found as a unique Content Type in the left-hand menu, under Users.

Aside, from a UI level change, the most fundamental change Strapi developers will confront is the need to create an additional End User. For example, if a blog or similar project is being developed that has a need to display the Admin User an “author”, a “profile name”, etc.

Simply put, an Admin User can access the Strapi dashboard. An Admin User may create content types, add content, manage API access, install plugins, etc.

An End User can only consume the API. This may include adding content but through the GET/POST methods in a form - not the Strapi dashboard. For example, for an ecommerce account, to leave a comment/review, to be the author of an article or otherwise have a profile.


But what about other blogging platforms? Those that do not separate the Admin Users from the End Users. This is a good point, but these platforms have been primarily developed around displaying website content and blogging. In that context, it might make more sense to keep both Admin Users and End Users in one database table. Strapi is much more than another alternative for solving blogging needs, we also include that as a capability, but Strapi is designed to do much more with content and APIs.

We made this change to how we handled Admin Users and End Users as an investment in the long-term roadmap of the Strapi project. A quick glance at the roadmap shows an even shorter-term step with the Administrators Roles & Permissions feature and then later, other features that are made cleaner in their implementation.

We felt that providing more granularity and control was worth the trade-off of extra complexity on our side but providing greater flexibility and features for our users. The approach of separating the Admin Users from the End Users allows for other features. Aside from upcoming features, by separating them, performance isn't affected due to, for example, the database structure.

In summary, separating Admin Users and End Users in the UI and database opens the door for providing features and functionality sought after by Strapi users. Their separation also avoids performance and database issues down the road.

Strapi is a 360° headless CMS. We are front-end agnostic as a headless CMS should be, but we are also database agnostic, allowing for a practically infinite set-up, configuration, and use. By being agnostic in this way, we are able to fulfill our mission to reinvent the way content is written and distributed to people. Separating the Admin User from the End User is just one step towards fulfilling the promise of a headless CMS.

Article written by your David in collaboration with Alexandre.

Latest comments (5)

Collapse
 
syang profile image
syang

Hi Strapi team,

We are trying to build a mini-Shopify-like e-commerce platform, and we wanted to allow seller to write blogs to drive organic traffic to their store.

What we do:

  • we allow the store owner to list their business (think of Yelp)

What we want to do (with Strapi or other headless CMS):

  • allow store owners to write blogs, basically this is a personal blog space

Is the above feature a good fit for strapi user management listed here?

Collapse
 
adriatic profile image
Nikolaj Ivancic • Edited

I spent some time discussing the idea of using IAM (Identity and Access Management) service providers like Auth0, OKTA, AWS IAM, with several of your team members (Derrick, Maxime, and Aurelien) in the context of a full-stack app where Strapi plays the backend role. Strapi being a generic CMS opens many new paths and I was very excited about this architecture. However, I made no impression on the three Strapi members who stated the using Passport.js as the basis for all subsequent AIM features implementation.

Assuming that I did not good enough "sales job", I decided to create a series of full-stack samples where the only constant is Strapi being used as the backend, while front ends and IM providers vary across most frameworks and PaaS providers. Having something real to show, might make my theory that Strapi is not just a toy tool, but could be used by Fortune 500 companies that all have very strict IAM requirements.

Collapse
 
maximusdb1 profile image
Maxim Nawangwe

Not a fan of this system. It sort of makes the admin panel only accessible to a user of super-admin status, hence editors cannot be granted access to the panel with limited functionality. this forces us to create another front end to consume the apis generated by the super-admin.

Collapse
 
lauriejim profile image
Jim LAURIE

Hello! In fact, it doesn't change anything from the previous system.
It's just now you have your user base and your admin base separate.
Before it was not possible to "grant access to the panel with limited functionality".
All you are talking about will come when we will develop this feature - portal.productboard.com/strapi/1-p...

Collapse
 
giacomocerquone profile image
Giacomo Cerquone • Edited

You can't understand how much I'm waiting for this feature Jim.
Thanks strapi for the great work!