Access rights management



  • Hi,

    Assuming that the backend id is public (or can be reverse-engineered from the client code), without ACL any registered user could potentially access the data of another registered user. So ACL is needed to protect users from each other, but how can the protection be automatically set at the user group level ?
    For instance, if I want user group A to be isolated from user group B, I can either:

    • set ACL on object types for both user groups so that the objects created by users of each group can only be accessed from that group, but that means two sets of objects types.

    • create a backend for group A and another for group B

    The problem of these two solutions is that they don't scale well to hundreds of groups or more. Is there another way to isolate user groups ?


  • cid:52:privileges:purge

    This could maybe be solved like this:

    Object type permissions:

    • allow both (all?) usergroups to create objects
    • set permission template so that only creator has all permissions

    Now when user creates object, add read permission for usergroup to object. Example if user belongs to usergroup "GroupA" then add following permissions to object:
    @
    {
    "read": [{"id": "GroupA id", "objectType": "usergroups"}]
    }
    @

    After updating object permissions only "GroupA" members will be able to read this object.



  • If I understand correctly, this solution allow users of a group to read objects created by other group users. But what I'd like is to give all users of a group R/W access on objects created by any user of that group. I could just change the permission you're suggesting to R/W instead of "read", right ?

    If that works, the drawback of that solution is that you have to do a permission change for each new object with a separate request. It's slower and not completely safe, if the network fails between requests the users could be stuck with wrong permissions. It would be better to be able to set permissions inside the create request - could that be a valid feature request for Enginio ?


  • cid:52:privileges:purge

    Yes, R/W permissions should work in that case. I agree that separate request is a little bit nasty... application must have good error/retry logic for those network issues.

    Reason why those permissions can't be set on create is that permissions are inherited from object type's template and/or from referenced objects (depending on permission configuration). This inheritance would be handy on your case if permissions could be inherited from "creator" (user).. unfortunately this is not the case atm.



  • bq.
    Yes, R/W permissions should work in that case

    OK

    bq.
    ...application must have good error/retry logic for those network issues.

    That's not really feasible in a web application where (for instance) a user can hit the browser refresh button at any moment

    bq.
    ...unfortunately this is not the case atm.

    I understand that, but if it makes sense, it could maybe be a feature request for a future version of the service ...?


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.