RBAC - Role based access control feature discussion

Some related feedback here as well:

You typed that word twice :grinning:

Ok, let’s wait to see…

I regularly stop typing to think about what I need to type and almost always forget to re-read what I wrote. :raised_hand: :stuck_out_tongue_winking_eye:

1 Like

Hello, any updates on this request? This is the most popular topic of the forum, so it sends a message on the lack of clarity we got from the Pricing page.

Maybe instead of saying “3 default roles” you should say “3 limited roles” so we understand It’s not only the number of roles, but what you can do with them?

6 Likes

Any news on this? It was quite measleeding also for me to see that a basic feature as RBAC is limited in such a way that does not allow any real kind of content approval process. It is odd that authors cannot see published content in the lists, in an editorial process the default distinction should be edit/no edit, not see/no see.
And as others pointed out the fact that the role numbers limitation is advertised and not the feature limitation is quite disappointing.
I also understand that development has its costs not everything should be given for free, but this is just making the community version useless in basic use cases. The single sign on is a good example of feature that is fine to keep in the paid version, IMHO.

3 Likes

Hi,
I totally agree with @Jason.
I also spent quite some time searching for the best solution for a project and then time for setting it up, only to find that I can’t prevent some roles from deleting content.
If I had known this in advance I would have thought twice about using Strapi especially that I already had experience with KeystoneJS.
Strapi seemed better for the current project, but this issue makes it almost unusable for my use case…

Has anyone figured out a clean way to prevent deleting content from a certain type ?
I tried doing that on the beforeDelete lifecycle hook, but then a generic error message is displayed when deleting, which makes it look more like a bug. Is there at least a way to customize the error message sent to the user when a validation error occurs in the lifecycle hooks ?

Note: I highly value the work done here, I just wish there was a bit more transparency upfront.

2 Likes

I’m new to using strapi personally, but I had some good experiences with it at my job. After much research and comparions, I decided to go with strapi as the cms for a simulation basketball league I made with my dad since it was the easiest to integrate into our current infrastructure. I managed to get AWS SES and S3 working great with it, using the available plugins. So far, so good.

When moving onto permissions (since I want other members of our league to write media articles, player interviews, etc.), I saw that the roles would limited to three defaults. I didn’t think that it would be a big issue, especially since one can change them a bit. Yet, the limitations of the configurations are strange.

For instance, in the documentation for Configuring administrator roles, it says that the roles can be changed only in the following limited ways:

  • You can only configure permissions for the content-types, but not for the plugins and settings of the Strapi application.
  • Configuring permissions in detail is only available for the Enterprise Edition. With the Community Edition, although you can choose which fields of a content type are accessible, these fields are automatically fully accessible with all permissions.
  • Custom conditions defined for a specific permission are also only available for the Enterprise Edition.

It’s particularly the second and third conditions that make it impossible (without paying $29/month at the lowest) to prevent authors from deleting their own content or to read other articles that they did not create. When I tried to select permissions for one of the content-types that was missed when clicking the reset button, it automatically gives full access even though the other content-types for authors is restricted. I believe this is caused by the second limitation: “You can choose which fields of a content type are accessible, these fields are automatically fully accessible with all permissions.”

magwXS4SfR

By limiting this, strapi doesn’t seem to allow moderation of content very easily. I would be fine with a smaller number of roles for the Community Edition as well as only allowing permissions for the content-types (like the first limitation). However, placing the ability change role permissions behind a paywall, which seems like it should be a basic feature of anything that has permissions, doesn’t seem fair for those who only need this one feature. I don’t need 30 roles, just three (really two since Super Admin does everything) that I can customize.

4 Likes

I understand the Strapi team needs to make money, but the limitations for roles is too much. I think we should be able to customize more the 3 roles we are limited to.

1 Like

Hi,

I totally agree with @Jason.

To me, the promise “always free” has been broken from the time you decided to monetized a core feature. I understand that you need to monetized your works but many other way should be explored as payant plugin, support…

Sorry if I’m a little hard in my words but it is up to my disappointment.

Regards

2 Likes

No problem we understand and appreciate the candor.

There are no discussions in this thread since May 21. Does this mean that @jason @SorinGFS @dneckel @gshah2020 @assainov @Camilo_U (and others participating in this thread, found solutions for their RBAC needs or they gave up asking.

After nearly a year long absence from Strapi (my key issue was the speed of the API changes - something that bugged me as a developer and what I applaud for to Strapi management team) I came back to verify statements from many of my friends that Strapi is by far the most popular CMS framework) If that indeed is the case, then Strapi was right running to the stable and sufficiently functional release.

Regards to my old fried @DMehaffy :grinning:

Hello @adriatic :wink:

We haven’t found any solutions to this problem. Currently deciding on the CMS for the next project and will pay better attention to the features like this.

@adriatic

No officially supported solution or official word.

I understand that you need to monetize somehow but when I encountered this, it really felt like a bait and switch to me. Especially when this is a self-hosted edition. I’ve invested many hours deploying servers and databases, setting up my models, and adding content to then find that I can’t create new roles and I don’t even have full functionality of the 3 free roles. You’re all great and I love Strapi but this just doesn’t feel right to me.

Thank you all for your candid comments, it’s really appreciated! The limitation on the RBAC feature in the CE is a mandatory path for us, as some of you mentioned, we have to make money and pay the core team working full-time on Strapi.

From a user perspective, I do understand how frustrating it can be. We tried to be more generous than our competitors when we released the RBAC CE feature while also trying to give as much flexibility as necessary for most of the use cases we identified. Obviously, it doesn’t work all the time and the limitations might not make sense sometimes.

I really wanted to write this comment to share with you the future of RBAC. We invested a lot of time and effort in the v4, we don’t plan to release new paid features in the coming months, so nothing is going to change for the next 6 months. However, our end goal is to make RBAC 100% free and unlimited, hopefully, next year. We don’t have an ETA yet because we need to replace it with another one that would make sense for enterprises only.

In our vision of a modern CMS, RBAC + Internationalization should be default and free features for all. The Internationalization feature is already free and unlimited. Please allow us a bit more time to find the financial equation that would make what I just wrote possible. We want the same thing and empower millions of people to manage and share content :slight_smile:

5 Likes

The problem isn’t that Strapi needs to make money, it’s more the bait and switch.

Why isn’t this clearly printed?

If you’re willing to bait and switch this, what other time bombs are there or will there be in deciding to use Strapi for a project?

This is a mark against your credibility as a platform and when a platform choice implies 100’s of hours of labor at 10’s of thousands of dollars even on the lower end, your credibility matters.

Honestly I have to agree, this is a bait and switch. I wish the Strapi team would focus on monetizing through offering a Cloud solution, and through plugins.

Look at how successful WordPress is - it’s 100% because it’s completely free for everyone.

For anyone else looking, I’d recommend Keystone.js as an alternative without this restriction

1 Like

unfortunately I have to agree 100% with the two previous postings.

This IS bait-and-switch and since it apparently has been an issue for almost a year and nobody cared to update the wording on the pricing page, it is done with full deliberation.

This is sad and should be the reason for anyone to leave the Strapi train as good as it may be, and as nice and great as the dev team may be. If the suits ruin it, run!

I can’t imagine anyone after figuring this out the hard way - as obviously many on this thread did - would be like “oh, hell yeah, I been tricked, but let’s give these guys money”.

So, no, I really do not understand the reasoning or why you feel it is “mandatory” (mean monetary?) for you to strip RBAC of any usability by taking away the possibility to set CRUD rules on the field level.

I’m veteran enough to hack my way out of this, but be assured that you will never see a cent from actual developers this way. Might get a buck out of a PR dude though. Good luck!

2 Likes

I think I got to fast exited by the name OpenSource until I realized that. :roll_eyes: