Public
Authored by Tamlyn Rhodes

Finite State Machine Workflow Authorisation

Edited
Readme.md 2.05 KB
  • 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

    So when can(user, 'edit', book) comes in, it's checked if user is author on the book, and if the author role's capabilities include edit.

    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 [{role:'operations'},{role:'author',object:123}]

    Where would this conditional link be described?

    I was thinking that these could be different actions depending on the current state. E.g. make decision vs change decision, edit draft book vs 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.

    Edited by Tamlyn Rhodes
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment