Finite State Machine Workflow AuthorisationEdited
So this is similar to the DSLoid thing that I was thinking about, i.e. when you look at an authsome mode with its nested ifs https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/server/test/helpers/authsome_mode.js#L58 and loops https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/server/test/helpers/authsome_mode.js#L14 a lot of this could be made more readable with some constraints. Specifically the above could be expressed as some form of :
Collections: unauthenticated: GET: filter: (collections) => collections.filter(collection => collection.published) authenticated: extends: unauthenticated teamMembers: POST: true PATCH: true
You can abstract this up or down depending on the need, but there are a lot of common authorization patterns across apps that could be abstracted away (i.e. team membership, filtering).
In terms of your proposal, which looks to me to be a kind of an abstraction of the current team-based system, I'll try to walk through a few examples and see if I get it.
Editing books where you're an author
We have the following role config
Author: capabilities: - edit book
What links the book to the author? Some kind of role table? Like you say, currently this is basically teams and team memberships.
id role type objectId 1 author book someBookId
can(user, 'edit', book)comes in, it's checked if user is
authoron the book, and if the
authorrole's capabilities include
Say you've done your edits, and the book is now in the final phases of production, the copy editor is looking through it.
Copyeditor: capabilities: - edit book
At this point the Author shouldn't be able to edit the book. Where would this conditional link be described? Currently this kind of thing is evaluated in the authsome mode, which is app-level code, which is also what you're suggesting, but do you have a different place in mind for storing these state-based conditionals?
The state machine is an interesting idea, and probably generally applicable to documents with state, but I'm not sure it ties directly to authorization. Feels like the question asked there is 'what can happen to a document/object', more than 'who can do the thing'. It's in the same spirit (in the 'what can happen full stop' way), but these two types of questions can be completely disconnected in principle.
My $4 for now. I'll give it more thought and work through another example.
What links the book to the author?
Current team structure would work but there might be a better way which combines it with general roles. i.e. user has a roles array like
Where would this conditional link be described?
I was thinking that these could be different actions depending on the current state. E.g.
edit draft bookvs
edit finalised book. I can also see some kind of hooks system to allow more complex logic to be added but they should only be used in exceptional circumstances to keep things simple.