JSON API Permissions

[sebgie]

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]

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

[peterhughesdev]

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

[ErisDS]

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

[d7p]

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]

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

[sebgie]

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]

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

[ErisDS]

👍

[hswolff]

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]

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]

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

[ErisDS]

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]

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]

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]

Dope :D 👍

[sebgie]

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]

This is done on the apps-perms branch