Roles

[digitalplaywright]

Permission control through roles would be great. Supporting the same roles as ghost would be great here:

• Admin: can administrate all parts of the blog and add users
  • not necessary to have an interface for adding users in the first version
• Editor: a user who has can manage and publish posts, including the posts of other users.
• Author: a user who can only publish and manage their own posts.

This can be enforced by storing a .netlify-cms.yml file with role permissions in the git repo and reject/permit commits through a git hook that reads this yml file.

[cassiozen]

For now, we are considering using GitHub's roles.
I'm closing this due to inactivity. Please feel free to reopen if you want to add to the discussion.

[erquhart]

Re-opening this, as roles is eventually something we'll want to have, and we'll need to implement for various backends, not just GitHub.

[tech4him1]

@erquhart Thinking about working on this -- How would we store the list of what user has what permissions?

[erquhart]

Awesome!!

I think we still need to discuss higher level arch, like whether to maintain a list at all.

So here's a crazy idea, and it might not even be a good idea, but what if we fork the source repo for authenticated users that don't have write access? Forks via api are supported across platforms, and this could keep us from doing too much heavy lifting within the CMS while maintaining a natural parity with expected git workflows.

[tech4him1]

@erquhart On #2, I also think we should keep it as much tied to the actual backend as we can: using PRs, forks, branches, etc.. In that case, then, we need to define the user permissions based on the backend roles. In particular, how should "authors" be able to editing their own posts, without having to get each edit approved?

[erquhart]

That would require write access to the repo.

So there's two layers:

1. The actual backend roles as you mentioned. This is the only real security - a user either has write access or they don't.

2. Using metadata, we can define what collections a user has access to, and perhaps other details pertinent to roles, ideally in some artificially obscure way so it isn't plain text. Maybe hashed and minified or something. This would apply to users with and without write access, but only serves to instruct the CMS app and can't actually enforce anything.

[z3ugma]

I'm a fan of this option:

Using metadata, we can define what collections a user has access to, and perhaps other details pertinent to roles, ideally in some artificially obscure way so it isn't plain text. Maybe hashed and minified or something. This would apply to users with and without write access, but only serves to instruct the CMS app and can't actually enforce anything.

I'd like a workflow where specific users' accounts can be limited to editing certain collections, or only entries they created, or limiting what statuses they can set entries to.

Ideally roles such as "creator", "editor", and "publisher" per collection

[jholmes033169]

The netlify identity/git-gateway already supports roles which allow.deny access to the entire admin. It seems like we could cover a lot of use cases by just adding a "role filter" property to collection configs, which would hide/show the collection based on the user's role.

I realize that this would not cover non-git-gateway configs, but this would be a low-hanging fruit option that covers a bunch of cases for those that do use the gateway with accepted roles.

[erquhart]

@jholmes033169 agreed on making better use of roles for Git Gateway.

It also looks like the branch protection and teams GitHub API's could be used to allow real roles in the GitHub backend as well. I'm thinking if a project uses editorial workflow and protects the CMS branch, roles can be accomplished through teams, and these new API's give us the info necessary to reflect said roles. Shout out to @rdebeasi for the inspiration on that, and as he also found, this will require images to go through the workflow and not direct to the CMS branch.

[Destroy666x]

Great news! I hope that all types of actions including differentation of collections and later media (#1046 - e.g. per folder permissions) will be covered.

[ghost]

I am very interested in this feature.

@Destroy666x Had a look in the linked issue and I wonder how this could affect roles and permissions. You mentioned the issue a couple of months later, without any context on why there are "great news". Could you explain that in more detail, please?

Roles per collection is one of the key features missing for me. Would this be – temporary – possible with Git submodules? Each collection would have it's own submodule. But could NetlifyCMS figure out if a logged in user has access to that submodule and display collections accordingly?

[erquhart]

The key issue with roles is that Netlify CMS alone cannot enforce them in any way, as it is a client side application. Either the backend service, eg. GitHub, must enforce roles, or else an intermediary like Netlify Identity/Git Gateway. Then the CMS can provide an interface based on those enforced roles.

[ghost]

@erquhart Yeah, I hope that GitLab will support directory based permissions in the future. But as a workaround, could NetlifyCMS work with submodules? The editors wouldn't get access to the main repo where admin lives.

[erquhart]

The submodules themselves as separate Git repos could be edited by Netlify CMS currently. That's probably as far as support would go for that particular route. Of course, you can always copy the GitLab backend and augment it with special functionality for your own purposes.

[julienchazal]

Hello @erquhart !
Any news about this feature ?
Thx

[RubenNijhuis]

Is there any news about this feature, I would really need it for my site. If not is there a way to mimic the behavior of roles having an effect on what is editable by a user? As in, only the admin may change files in the editorial workflow?

[jaimehing]

hi guys, I love netlify cms! Any news about this feature?

[erquhart]

Still the same issue: #2 (comment)

[austincondiff]

Moving the conversation here, as stated in #2661 (comment)

We would simply check what the value of the author field is (relation widget pointing to the users collection which is configured to be tied to Netlify users). If it is equal to the current users id/username/email (whatever is used to identify them with), then they can edit/save it if a permission role requirement is set on that collection in config.yml.

We cannot yet validate on the server side, but we can on the client side which is better than not providing this functionality at all.

It looks like users have wanted this feature for over four years. 🤯Correct me if I am wrong here, but I think it's time to get creative despite these limitations. We might make users aware when setting up these roles via a disclaimer message that this cannot be validated server side and the repercussions associated with that.

In theory, most content creators are not technically aware enough to perform this type of operation (get the GitHub API key that Netlify CMS uses to submit a backend request to modify the desired file). For those that are that smart, GitHub and Netlify keeps logs of commits and builds respectively. I don't think it would be very difficult to identify who abused that API key and take appropriate action if necessary from an organization level. Developers would be able to roll back the malicious contributors change as well. We might provide the tools to do this. (Keep a log file of commits that were made by which user, then admins would be able to roll back those changes. You will be able to tell via git if and entries to this log file were ever maliciously modified).

Regardless, in my opinion, offering some kind of role limit, though it is not ideal, is better than not offering this at all, as I mentioned. Then we will be ready when this type of backend validation is supported by GitHub and the rest. Thoughts?

[erquhart]

Fake roles are risky. Not saying we'll never do it, but it's not a current priority. It's also a much lower priority for the community than the other things we have our sights set on, based on how often we're asked about it and this 3 year old issue having only 17 reactions.

_{Sent with GitHawk}

[austincondiff]

There may be another way. Just brainstorming so it may be crazy. What if Netlify had a service to mask the API key Netlify CMS now uses and exposes to the user? We funnel all requests through this service so the API key is never exposed. This could be a means of some kind of backend validation, not via GitHub, but via Netlify.

[erquhart]

Also note that people wanting a feature for a long time doesn't make the product team have bandwidth to implement. This is true for any product and especially true for open source. We have metrics on what the community is actively requesting, and also on the priorities that are important to us as maintainers from a product vision standpoint.

Out of respect for the effort that goes into this product by many community members, most of which are not paid, please be considerate in your constructive criticism. No one is being lazy, there's just a lot to do here. You're welcome to pitch in.

_{Sent with GitHawk}

[austincondiff]

It's also a much lower priority for the community than the other things we have our sights set on, based on how often we're asked about it and this 3 year old issue having only 17 reactions

True. Just to give you my point of reference, I also saw that this issue has been referenced in 10 other issues. I believe you though.

Out of respect for the effort that goes into this product by many community members, most of which are not paid, please be considerate in your constructive criticism. No one is being lazy, there's just a lot to do here. You're welcome to pitch in.

No offense intended. 😉 I understand this and I'm not intending to be critical by any means nor calling anyone lazy. I apologize if that came across differently. I love this project and I am more than happy to contribute and I feel like I have in other issues by way of design. By way of implementation, I am just trying to gauge where I can be most helpful by first being involved in these issues.

[sharadcodes]

The key issue with roles is that Netlify CMS alone cannot enforce them in any way, as it is a client side application. Either the backend service, eg. GitHub, must enforce roles, or else an intermediary like Netlify Identity/Git Gateway. Then the CMS can provide an interface based on those enforced roles.

you can save it on another repo just made for users and request access to it

[erquhart]

That removes direct access to the repo, but doesn’t provide actual roles, Eg., specific collections for specific authors. We just released Open Authoring that uses a fork the way you’re describing, in case that fulfills the needs of anyone waiting for this.

_{Sent with GitHawk}

[sharadcodes]

That removes direct access to the repo, but doesn’t provide actual roles, Eg., specific collections for specific authors. We just released Open Authoring that uses a fork the way you’re describing, in case that fulfills the needs of anyone waiting for this.

Sent with GitHawk

What about using the config from admin folder to store the permissions for users:

collections:
  - posts:
      users:
        - email: "admin@example.com"
          create: true
          delete: true
        - email: "user2@example.com"
          create: true
          delete: false
  - news:
      users:
        - email: "admin@example.com"
          create: true
          delete: true

[PetroPavlenko]

hi guys, I love netlify cms! Any news about this feature?
I'm thinking about contribution and adding new boolean value to integrate role-based-access-control with git-gateway
and potentially integrate it with other backend(eg: custom)

[erezrokah]

Hi @PetroPavlenko, we would love a contribution! Thank you for suggesting 😄
I'm not sure how git-gateway handles roles (I think it either allows or disallows access according to the docs: https://docs.netlify.com/visitor-access/git-gateway/#setup-and-settings).
I do know someone on the Slack workspace posted they managed to use branch protection to simulate roles and I think that might work with all backends.
e.g. The CMS would identify if the current user has admin access to the repo, then will display a toggle button to restrict publishing by non admins (which will be mapped to a branch protection rule).
A second iteration would be to split that into roles, and allow adding editors (non admin users that can publish) which will be mapped to adding allowed users to the branch protection rule.
This is just a suggestion and I'm probably missing a lot of stuff.

[PetroPavlenko]

@erezrokah Thanks for the support. Looks super helpful.
Currently my team wors on different tasks. But we will back to roles in 1-2 months

[MinasG]

Any update on roles? 😄

[aviavia]

I would like to suggest something like that:
//collection level
"app_metadata": {
"authorization": {
view : {
roles: ["admin", "editor"],
creator: true
"edit": {
roles: ["admin", "editor"],
creator: true
"delete": {
roles: ["admin", "editor"],
creator: true
}
limitation : {
creator max documents: 30
}
}
// same on the field level.

[0xAlwaysDumpling]

is there a way to hide entries based on roles just client side?

[cbeauhilton]

@0xAlwaysDumpling I use filters and hidden defaults to help with this. Not perfect, but helpful.

When users create posts there is a hidden "admin" field automatically created that defaults to "false." If I want to lock down a post, I go to the markdown source directly and change it to admin: true. Then the CMS will no longer show it.

example admin/config.yml:

`
...

collections:

- name: 'assignment'
  label: 'Assignment'
  folder: 'content/assignments/submissions'
  create: true
  slug: '{{year}}-{{month}}-{{day}}-{{author}}-{{slug}}'
  filter: {field: "admin", value: "false"}
  fields:
    - { label: "Admin", name: "admin", widget: "hidden", default: "false"}
    - { label: 'Title', name: 'title', widget: 'string' }

`

[truesteps]

bump

[eoinparkinson]

Netlify, on a paid plan, does allow you to lock down specific urls within a site based on the current logged in user, just as a really shabby alternative for this. It would be great to see something like this if the team behind Netlify CMS are still developing with the rebranded Decap CMS.

There is an "up-to-date" fork of Decap called Static CMS, however even they seem to not support such a feature.

[martinjagodic]

@eoinparkinson I doubt that this is something we can include, as there is no sign of API access to this feature. It's also for paying customers only, but we want to make this available to everyone.

[eoinparkinson]

I doubt that this is something we can include

Apologies, I meant as a temporary solution to anyone who is checking this issue for an update on user roles.

Not asking for free access to a paid solution 🙂