[Cms] More granular user permissions (per page, per template) for API

[ghost]

@bnomei commented on Apr 13, 2018, 3:05 PM UTC:

I know various solutions have been discussed in a livestream. just wanted to track progress with this issue.

what i would like to have a solution for is this:

1. frontend read only user like this.

title: Visitor
permissions:
  access:
    *: false
  site:
    *: false
  pages: # should be page
    *: false
  users: #should be user
    *: false
  files: #should be file
    *: false

2. but i would like to block that user using the api to query some pages or just pages with a certain template or a more advanced filter. like the user visitor should only be able to query pages of template visitor.

This issue was moved by bastianallgeier from k-next/kirby#420.

[ghost]

@lukasbestle commented on Oct 19, 2018, 7:38 PM UTC:

From k-next/plugins#87 (comment):

Some sort of system in the style of .gitignore. Ideally devs would be able to restrict access to site-, users-, translation, system and page endpoints of Kirby. Maybe even an option to exclude certain fields within a page that is otherwise accessible or an option to filter content.

I like the .gitignore idea. Could potentially be a bit hard to parse, but is very easy to understand and very very flexible.

[ghost]

@bnomei commented on Oct 20, 2018, 8:04 AM UTC:

maybe instead of *: false one could use !: users/editor-ignore where the editor-ignore file is just like a file with gitignore syntax.

like this...

permissions:
  !: users/default-ignore
  files:
    !: users/editor-files-ignore

[ghost]

@bastianallgeier commented on Oct 21, 2018, 10:37 AM UTC:

Our concept is the direct opposite of this. The user blueprint sets the general permissions for a role, but the blueprint of each model (File, Page, User) can be used to overwrite this more particularly. So far we only have this working with disabling or enabling options for all roles, but in a next release it will be possible to do this for example in a page blueprint:

title: My Page
options: 
  read: 
    admin: true
    editor: true
    client: false
  update: 
    admin: true
    editor: false
    client: false

With this you get very fine grained permissions without having to write complex code for it. Additionally you can still use Page models to manipulate permissions further.

[ghost]

@lukasbestle commented on Oct 21, 2018, 12:40 PM UTC:

The permissions in the page and file blueprints make it possible to restrict access to different types of objects. But as far as I can tell, it's not possible to define them per object (specific page or file) without having to use models.

I think that this is what the suggestion was about. It may not be entirely useful for Panel users, but in the API client context it can make sense to grant permissions to an API user just for a specific page that you want to access from an automated system for example. And for that use-case, the .gitignore syntax is very useful.

In the end, it would be an additional layer of permission definition. You could define permissions per user role in general, then for each blueprint specifically and for use-cases like this even finer with a .gitignore syntax for specific API endpoints.

[bastianallgeier]

✅