Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

JSON API Permissions #2264

Closed
sebgie opened this Issue Feb 25, 2014 · 18 comments

Comments

Projects
None yet
7 participants
Member

sebgie commented Feb 25, 2014

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
Owner

ErisDS commented Feb 25, 2014

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 commented Mar 1, 2014

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 api labels Mar 4, 2014

@ErisDS ErisDS added this to the 0.5 milestone Mar 4, 2014

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

Owner

ErisDS commented Mar 7, 2014

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

d7p commented Mar 8, 2014

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 commented Mar 8, 2014

A subscriber is (should be) merely a role, like any other, so the
permissions for each deployment should be editable like any other role.
A subscriber may have read-only permissions but may also have additional
permissions, to post comments, or access premium content identified by
section/topic or tag or whatever other criteria. The point here is to be
as generic as possible in the core implementation of role based
permission not only on the web UI side but also on the API access side.

On 3/8/14, 3:06 PM, Dan wrote:

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.


Reply to this email directly or view it on GitHub
#2264 (comment).

Member

sebgie commented Mar 11, 2014

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?

Member

sebgie commented Mar 12, 2014

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

Owner

ErisDS commented Mar 13, 2014

👍

Member

hswolff commented Mar 13, 2014

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.

Owner

ErisDS commented Mar 13, 2014

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.

Member

sebgie commented Mar 13, 2014

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 👍. 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 :-).

Owner

ErisDS commented Mar 13, 2014

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.

Member

hswolff commented Mar 13, 2014

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.

Member

sebgie commented Mar 13, 2014

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.

Member

hswolff commented Mar 13, 2014

Dope :D 👍

Member

sebgie commented Mar 17, 2014

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 Apr 5, 2014

Closed

ACL for Apps #2059

sebgie added a commit to sebgie/Ghost that referenced this issue Apr 8, 2014

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

sebgie added a commit to sebgie/Ghost that referenced this issue Apr 8, 2014

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

@ErisDS ErisDS modified the milestones: API, 0.5 Apr 15, 2014

@ErisDS ErisDS added epic and removed epic labels Apr 15, 2014

Owner

ErisDS commented Apr 15, 2014

This is done on the apps-perms branch

@ErisDS ErisDS closed this Apr 15, 2014

@ErisDS ErisDS modified the milestone: 0.4 API Apr 16, 2014

sebgie added a commit to sebgie/Ghost that referenced this issue Apr 16, 2014

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

morficus pushed a commit to morficus/Ghost that referenced this issue Sep 4, 2014

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

@ErisDS ErisDS added permissions and removed apps labels Oct 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment