Roles - RBAC

[NathanBland]

This is a working guide of what needs to happen RBAC wise for habitus.
It is by no means a final model.

Each role will have a quick description along with proposed permissions.

Roles:

• admin
• user
• author

admin

The ruler of the land. King of the castle. Owner of Habitus. There should always be one of these on an install, or bad things will happen.

Permissions

• users
  • Create
  • Read
  • Update
  • Delete
• pages
  • Create
  • Read
  • Update
  • Delete
• comments
  • Create
  • Read
  • Update
  • Delete
• tags
  • Create
  • Read
  • Update
  • Delete
• posts
  • Create
  • Read
  • Update
  • Delete

user

A generic user, like you might find on a forum if you need a comparison. They can generically create/manage their own comments, and modify their own account.

Permissions

• users
  • Sub-notes: Create here is really for the register route, not a user itself. All other permissions should be for self only
  • Create
  • Read
  • Update
  • Delete
• pages
  • Read
• comments
  • Some additional notes here. We will want a user to be able to edit or delete their own comment, but not other user's.
  • Create
  • Read
  • Update
  • Delete
• tags
  • Read
• posts
  • Read

author

Sort of like a hybrid of admin and user. These would be users that are writing content for the website, but aren't trusted with admin permissions for the system.

Permissions

• users
  • same as user
• pages
  • Read
• comments
  • same as user
• tags
  • Create
  • Read
  • Update
  • Delete
• posts
  • Create
  • Read
  • Update
  • Delete

Notes

If there are any questions, or role suggestions, add them in comments here, and @ me.

[crodeheaver]

I suppose I'll have to do a lookup on the user each request. Which means you'll have to be passing me that info each time
@NathanBland

[NathanBland]

I'm sending an authorization for each request made, if that's what you mean...

As an example:

Request URL:https://habitus-crodeheaver.c9users.io/api/v1/pages/index
Authorization:Bearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJVc2VyOjIiLCJleHAiOjE0NzA1OTYxMzUsImlhdCI6MTQ2ODAwNDEzNSwiaXNzIjoiSGFiaXR1cyIsImp0aSI6ImUzMzg0MDMyLTJhZjctNGIwZC1hOTYyLTlhMDE2Yjc5MDY3ZCIsInBlbSI6e30sInN1YiI6IlVzZXI6MiIsInR5cCI6InRva2VuIn0.9NEdsYK63pwsPZmmdN0FuwLaqhAvM1eQsDJrGaLb_vb2DVMCXCFKW7xaopLExvscbEdZoAKwiPNOJiJtg47vtQ

Unless of course, no one is logged in. Then that isn't passed.

@crodeheaver it should probably also be mentioned that as an anon user, I should have read on everything except password hashes and such.

[crodeheaver]

I suppose if I store the token like I should be.... then I can use that. But then I get into checking for out of date stuff... and that's annoying

[NathanBland]

@crodeheaver You could probably just deserialize the token on each request? and look the user up from that.

[crodeheaver]

Indeed. It looks like that is the case.

[crodeheaver]

I guess I should add roles to the users