How do you guys restrict this?
There is this ticket that says it’s not a bug: Any role that can create users can create Super Admin user. · Issue #16297 · strapi/strapi · GitHub
but I just can’t believe what I’m reading “by giving a user the ability to create others there is some level of trust that must be given to that user”. There is a difference between allowing someone to create new users and allowing someone to create a user who can create a new super admin and do everything from now on including removing us from the system. This is crazy! How on earth is this not a bug?
This topic has been created from a Discord post (1258717568433131582) to give it more visibility.
It will be on Read-Only mode here.
Join the conversation on Discord
i supposed you definitely should understand and filter with aproprietary logic types of roles that user (with given rights) are able to create…
1 Like
We do not have a hierarchical user management system like say Discord does. It’s just a simple true false are they allowed to create users or not.
1 Like
I get it that you don’t have a hierarchical user management system, but there is a huge difference between any other claim and the one that allows a user to create a super-admin. Only a super-admin should be able to create other super-admin accounts. If I’m allowing someone to create other editors I don’t want that person to be able to create a super-admin and give them any claim they want.
1 Like
I agree strongly with this. For our service, we want the main/primary editor to be able to invite other Authors and Editors - but they can also invite Super Admins, which is definitely not desirable for us.
Has anyone found a workaround for this? If not, we might do some investigating on how to completely block/prevent new super-admins from being invited or otherwise created. It won’t be pretty, but it’s essential for our use-case of Strapi.
1 Like
Our permissions system doesn’t have that capability. It’s quite literally the definition of a hierarchical user management system (can’t promote or create anyone above your role, thus a hierarcy).
1 Like
I’m sorry but I’m just not buying it. This is a huge security issue and I’m getting more and more convinced that Strapi doesn’t care about security at all. I’m an admin for a couple of facebook page, and youtube channels. I can add permissions for users to be able to do some things, but none of the creators, authors, or moderators will ever be able to create a super admin and remove me from my channels. Another great example is that the excel export plugin that is approved by Strapi. It’s not secured at all. It’s opened to public and if you know the api url you are able to just download the file. I do have doubts if I should still use Strapi as a CMS.
1 Like
It’s not so much a security issue as it is a feature request. You can prevent people from inviting super admin users by just revoking their rights to invite users as a whole.
1 Like
<@752476861904191499> that’s an issue with the plugin, it should be reported to maintainer. As for the admin permissions as Boaz has said, it’s not a security issue, it’s a feature request. All of those platforms you mentioned have a hierarchical permissions system which as I’ve said multiple times now, we don’t have. Our permissions system is a grant system but it’s binary, they can either do something or they can’t. They can either invite users or they can’t, that’s it for now.
1 Like
Just out of curiosity, is this changing in v5 or even v6 by any chance?
1 Like
Is there any chance we could see a setting added to v4 that simply only allows a single super-admin to be active? If the setting is active, “Super Admin” could just be hidden from the Roles field while inviting users.
If not, would you happen to know if we can implement this ourselves in any sort of way through “Backend Customization” - be it middleware, policies, custom controllers or otherwise?
I’m honestly dreading the thought our users are going to have to contact us for every editor/author they want added to the CMS, as we simply can not allow super admins to be created for our use-case of Strapi. We definitely can’t trust them to just not add any Super Admins.
Thanks for your clarification on this issue/question this far!
1 Like
For v5 no, that would be a breaking change and we are in the RC phase. V6 I’m not sure.
I’ve not tested do any customization on this but I do know the permissions system and the deeper non-documented scopes system are very complex.
If a user can’t be trusted to create users properly I would give that permission at all. What’s your use case?
why not just add a simple role code exclusion list (e.g. [“strapi-super-admin”, “…”] to the strapi config, which is used for filtering roles on user creation (and role selection)?
1 Like
I see. We’re launching a global game-server (think Steam games like DayZ, Rust, FiveM, etc.) monetization platform through Stripe Connect, and we only onboard the server owner onto the Strapi instance with the Editor role.
Game-servers usually have plenty of administrators that contribute to all aspects of their community, including their (potential) websites. We’re currently in the beta phase with 10 active instances, and have already had many requests for additional contributors to be added to their CMS instances.
We, as the platform facilitators, have to go into their instance and add every additional Author/Editor manually - as the initial Editor definitely can’t be trusted with the permission to create or invite users. This would be okay if Super Admin wasn’t made available to them.
We’ve considered the following:
- Generating a generic (service) admin email address with strong password that they can share. Insecure, invalidates sessions, and all-around not a viable solution.
- Intercepting incoming requests that try to invite a new user with the Super Admin role on the web-server level, and rejecting the request altogether with a 403 states. This works, but the user-feedback is obviously lacking in this approach.
- Having an automated ticket panel on the service website and Discord server, that collects the required information and only allows Author and Editor to be chosen for roles. This sounds fine in practice, but we haven’t checked if this (inviting users through the API) is possible yet.
We would definitely appreciate any additional insights you can offer 
1 Like
Hello <@1148597817498140774>
Here is a way you can wrap the creation method. this is considered experimental for now
For example in
src/index.js
'use strict';
module.exports = {
/**
* An asynchronous register function that runs before
* your application is initialized.
*
* This gives you an opportunity to extend code.
*/
register({ strapi }) {
strapi.get('controllers').extend('admin::user', (ctrl) => {
const baseCreate = ctrl.create;
return Object.assign(ctrl, {
async create(ctx) {
// you can also use koa-compose
if (ctx.state.user.roles.some((role) => role.code === 'strapi-super-admin')) {
return baseCreate(ctx);
}
const selectedRoles = await strapi.db.query('admin::role').findMany({
where: {
id: {
$in: ctx.request.body.roles,
},
},
});
if (selectedRoles.some((role) => role.code === 'strapi-super-admin')) {
return ctx.badRequest('You cannot create a user with super-admin role');
}
return baseCreate(ctx);
},
});
});
},
/**
* An asynchronous bootstrap function that runs before
* your application gets started.
*
* This gives you an opportunity to set up your data model,
* run jobs, or perform some special logic.
*/
async bootstrap({ strapi }) {},
/**
* An asynchronous destroy function that runs before
* your application gets shut down.
*
* This gives you an opportunity to gracefully stop services you run.
*/
destroy({ strapi }) {},
};
We do not guarantee the internal APIs will be stable over time and this si definitely playing with them.
Another method is to intercept the route itself and add a middleware
const routeConfig = strapi.admin.routes.admin.routes.find(
(route) => route.path === '/users' && route.method === 'POST'
).config;
routeConfig.middlewares = [...(routeConfig.middlewares ?? []), handler];
A recommendation if you are using internal APIs is to make sure you use exact semver versions in your package.json to avoid getting automated patches that might break your extensions of internal code
This is amazing, can’t wait to try this in a couple days (currently recovering from surgery, it’s not that I don’t want to test right away haha) - and I’ll let you know how it goes here
I really appreciate the effort put into making sure the service works for our use-case, along with the complete example - thank you!
Cool. Take care mate. Good recovery !
When starting with this exact script, unmodified, I’m getting the following error:
TypeError: strapi.get is not a function
Is this for v4 or v5?