Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

JSON API Permissions #2264

Closed
sebgie opened this Issue · 18 comments

7 participants

@sebgie
Owner

In preparation for #2058, #2059 and #2124 I have summarized a list of roles and their permissions for the JSON API. This is not a complete list of API functions yet.

Roles

  • Admin: somebody who has access to all the administration features on your blog.
  • Editor: somebody who can publish and manage posts including the posts of other users.
  • Author: somebody who can publish and manage their own posts.
  • NoAuth: somebody who is not authenticated yet.

Posts

JSON API Admin Editor Author NoAuth
posts.browse y y y (status == published or created_by == self) y (status == published)
posts.read y y y (status == published or created_by == self) y (status == published)
posts.edit y y y (created_by == self)
posts.add y y y
posts.destroy y y y (created_by == self)
posts.getSlug y y y

Settings

JSON API Admin Editor Author NoAuth
settings.browse
- core
- blog y y y y
- app y y y
- theme y y y
settings.read
- core
- blog y y y y
- app y y y
- theme y y y
settings.edit
- core
- blog y
- app y
- theme y

DB

JSON API Admin Editor Author NoAuth
db.exportContent y
db.importContent y
db.deleteAllContent y

User

JSON API Admin Editor Author NoAuth
users.browse y y y
users.read y y y y
users.edit y y y (user == self)
users.add y y
@ErisDS
Owner

This highlights something which has been on my mind but I don't think I've articulated well in the existing issues.

The status of a post (published or !published) is incredibly important to permissions. It is also very important that we are able to determine this in this boolean style - 'published' vs 'not published', and that we do not depend on 'published' vs 'draft' because this will fall down when other kinds of statuses like 'queued' come along.

Published is effectively a special state of post, only published posts get the special rule of being readable with noAuth.

@PunKeel

Hi,
I think there might be a permission for post.publish, so the user can create an article, preview it ... but not publish it.

Thanks for being awesome :)

@ErisDS ErisDS added this to the 0.5 milestone
@peterhughesdev

Agreed; publishing and unpublishing/deleting posts seems like actions that would be more applicable for an Editor role.

@ErisDS
Owner

I believe that noAuth will need read access for users in order to get post author info etc?

@d7p
d7p commented

Hi

I think you have missed one final type of user, the authenticated read only user ( or subscriber).

These user would not be taking part in any content editing but have a login and access to 'premium content' or other features.

Subscribers would have similar permissions to the noAuth but access to users .browse .read .edit.

Just a thought.

@hillct
@sebgie
Owner

I believe that noAuth will need read access for users in order to get post author info etc?

I'm not sure about this one? If noAuth is allowed read access for users, a random visitor of the blog would be able to iterate through the list of users by trying more or less random IDs. In that case even users who have never published a post would be publicly accessible? I think that denying public access to users and adding the author of a post if needed would be a more secretive approach?

@sebgie
Owner

Updated:
posts.destroy for authors is only allowed if the post was created by the author himself.

@ErisDS
Owner

:+1:

@hswolff
Collaborator

Just read through this, overall this is really awesome work @sebgie, really excite to see this included.

I do have a few notes however :).

Posts
For author role why must the status be published for them to access posts.browse, posts.read, posts.edit?

I also agree with what others mentioned, an author shouldn't necessarily be able to publish a post without an editor or admin approving or publishing it themselves. Is this addressed?

Settings
I'm not sure I agree that an Author role should be able to browse and read blog, app, theme settings. It's not related to their primary role of authorship of posts and seems odd that they have that permission.

Everything else looks great to me.

Not directly on topic but directly related, it may be best to approach this more modular. Instead of allowing for just 4 pre-defined types with set permissions I would venture that we could just offer them as 4 defaults included with Ghost.

This means that you'd be able to create a new role and assign permissions in a similar matter to how you outlined them above.

It will be more work, but I think easier to implement now than later.

@ErisDS
Owner

Not directly on topic but directly related, it may be best to approach this more modular. Instead of allowing for just 4 pre-defined types with set permissions I would venture that we could just offer them as 4 defaults included with Ghost.

This is exactly what we are doing? I'm not sure what you would imagine doing differently, but in the fullness of time we fully expect people to create their own roles or edit the existing ones - those in Ghost are just the defaults.

@sebgie
Owner

For author role why must the status be published for them to access posts.browse, posts.read, posts.edit?

Good catch, that is not correct :+1:. posts.browse, posts.read allows to read all posts created by the author or were published by another user. post.edit should allow to edit posts that were created by the author only. I have updated the issue.

I also agree with what others mentioned, an author shouldn't necessarily be able to publish a post without an editor or admin approving or publishing it themselves. Is this addressed?

No, that is not addressed yet. The assumption was that an author is allowed to publish his own posts. @ErisDS / @JohnONolan any thoughts on this?

I'm not sure I agree that an Author role should be able to browse and read blog, app, theme settings. It's not related to their primary role of authorship of posts and seems odd that they have that permission.

The reasoning was to allow an author to see the current settings (blog), installed apps (apps) or available themes (theme) without being able to change any of those settings.

This means that you'd be able to create a new role and assign permissions in a similar matter to how you outlined them above.

I think this is a 0.6 task :-).

@ErisDS
Owner

FWIW - having a UI for creating new roles, permissions, and advanced publishing workflows where editors are responsible for certain authors etc, is part of 0.8 'magazine features'.

In my opinion having authors not able to publish anything at all is a sensible default. Publishing = making something publicly available. I think it makes sense to have a user level who is not admin who can do this, and one who cannot.

@hswolff
Collaborator

Just to clarify, when I wrote of allowing for creating new roles I didn't mean for the UI and that flow to exist in 0.5.

What I meant was to create the system to later allow for that. So we don't shoe-horn ourselves into making static definitions and then migrate them to dynamic ones. Just create the architecture for there to eventually be dynamic creation of roles but only allow for 4 pre-set ones at this point.

Hope that's a little clearer, and forgive me if I'm repeating what was already intended.

@sebgie
Owner

What I meant was to create the system to later allow for that.

I understand now what you mean ;-). The permissions and roles are all managed in the database. The static definitions that are in place right now are the default settings that are stored in the database when it first starts.

@hswolff
Collaborator

Dope :D :+1:

@sebgie
Owner

I believe that noAuth will need read access for users in order to get post author info etc?

With the use of JSON API it makes sense to grant read access to noAuth to get post author, creator, publisher infos. My original reasoning was to include the user in the post, but as the user is linked now this concept is not working anymore. I have updated the issue.

@ErisDS ErisDS referenced this issue
Closed

ACL for Apps #2059

@sebgie sebgie referenced this issue from a commit in sebgie/Ghost
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
36ff94a
@sebgie sebgie referenced this issue from a commit in sebgie/Ghost
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
2e83578
@ErisDS ErisDS modified the milestone: API, 0.5
@sebgie sebgie was assigned by ErisDS
@ErisDS ErisDS added epic and removed epic labels
@ErisDS
Owner

This is done on the apps-perms branch

@ErisDS ErisDS closed this
@ErisDS ErisDS modified the milestone: 0.4 API
@sebgie sebgie referenced this issue from a commit in sebgie/Ghost
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
e47e9c6
@GoOz GoOz referenced this issue from a commit
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
e63d4fb
@GoOz GoOz referenced this issue from a commit
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
8bbb11a
@GoOz GoOz referenced this issue from a commit
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
9f73104
@morficus morficus referenced this issue from a commit in morficus/Ghost
@sebgie sebgie Add permissions to API
closes #2264
- added permissions check to db, users and posts
- added register method to users
- added doesUserExist method to users
- added user from session to internal calls
- changed permissible to overwrite canThis
- removed action map and action type from permissable method
1a0a83c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.