Skip to content

[PROPOSAL] Add an 'Active' column to Roles #4591

Description

@georgesjamous

Currently, i cannot think of a way to disable a Role without deleting it, and keeping a copy under a different name. Then copying it back, with all children roles and users under its initial name.

I think it would be a good idea to address a new Column called "Active" (or Enabled) in the _Role class that is initially set to TRUE. Users with Role write ACL will be able Activate or deactivate this Role.

So any Objects protected by this role (or its children roles) will be locked until this role is activated again.

Simple Example:
RoleA {has privilege A }
RoleB under RoleA {has privilege B & A }
RoleC under RoleB {has privilege C & B & A }

now when RoleB is disabled.
Any objects with RoleB ACL are now Locked (depending on the ACL of course)
Users with RoleC will only have privilege C (since RoleB will not be accessible when performing RolesOfRole() _keep reading_)

I am not greatly familiar with the internals of parse-server and how it gathers the user's roles whenever there is a query. But this task should be fairly simple by addressing a new constraint requiring the 'Active' collumn not to be FALSE (not == TRUE, to be able to support previous schemas maybe), whenever the user's roles or the RolesOfARole are fetched.

However, this constraint should not be added on all queries, where it is intended to aquire the Roles, for example in Parse.Cloud, rather it should be deeply available only when aquiring the Roles of a user for a query security. (hope it makes sense !)

I think this would be a powerfull addition where multiple user privileges segmentations can be easilly achieved by just disabling or enabling a Role.

Activity

  1. flovilmart commented on Feb 27, 2018

    @flovilmart
    Contributor

    If you set the ACL to masterKey only, does it help? from the logged in user's perspective, the role won't yeild (should not yield).

  2. georgesjamous commented on Feb 27, 2018

    @georgesjamous
    ContributorAuthor

    Yes it is a possible solution, but i was aiming for a more simple one since the Role's ACL will also need to be kept saved somewhere. This is required to be able to revert the role back to its initial state.

    i think a simple 'Active' field would make more sense, don't you ?

  3. georgesjamous commented on Mar 30, 2018

    @georgesjamous
    ContributorAuthor

    @flovilmart question, did you mean to set the ACL to masterKey only, on the Role or on all objects protected by the role?

  4. flovilmart commented on Mar 30, 2018

    @flovilmart
    Contributor

    Only on the role, which is the same ideally as the ‘active’ state

  5. georgesjamous commented on Mar 30, 2018

    @georgesjamous
    ContributorAuthor

    I tried this, but the object was fetched anyway.
    Can you confirm that this should not happen?

    Created a Test class with only one object.
    Set the object's ACL to a Test-Role.
    Added the user to the Role and set the role's ACL to masterKey Only.
    Then I used the following query to acquire the object with the user's session token.

    const query = new Parse.Query('Test');
    query.find({sessionToken:'r:79fcffc974a0f3dd56fd8c17ba3feec7'}).then(function( objects) {
      objects.forEach(element => {
        console.log('ID ' + element.id);
      });
    });
    

    Result:
    Log : ID 5aH0dnRY7H

    Expected:
    As I understand the query should not yield any results right?

    Version:
    "parse-server": "2.7.4"

    here are some screenshots:
    testobject
    testrole
    testuserinrole

  6. flovilmart commented on Mar 30, 2018

    @flovilmart
    Contributor
  7. georgesjamous commented on Jun 1, 2018

    @georgesjamous
    ContributorAuthor

    @flovilmart
    I will try and give it a shot and try to peek under the hood.
    There is only one class where the ACL fix should happen right ?

    in Auth.js
    L136
    L194

  8. flovilmart commented on Jun 1, 2018

    @flovilmart
    Contributor

    I’m not sure immediately on the top of my head, but that’s around that

  9. georgesjamous commented on Sep 4, 2018

    @georgesjamous
    ContributorAuthor

    Closing this because of #4821 and #5000

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions