Admin tool permissions / unable to get a new roles to work with tool

Bugs
1

Enonic version: 6.12.2
OS: Windows 10

What I tried to do, that caused this dive into the depths:

This role doesn’t affect admin tool visibility at all, only system.admin sees it.

After trying to figure out why this doesn’t work I ended up inspecting the roles in the repo browser:

I am trying to create a new role, but my admin tool doesn’t seem to become available for users with that role. Is there a bug with creating new roles in the Users app, that is bundled with XP?

While trying to figure out why the user didn’t get access I dug into the roles in the system-repo, and my new role doesn’t seem to consist of the same data schema as other, functioning, roles in the system-repo.

My goal was to define a new role that is referenced in my admin tool as an principal. Does the text you specify in the allow part need to match the _id-property of the role in the repo? With the latest version of the Users app, all the roles I create are assigned a random _id, but all our other older roles have f.ex. “role:system.admin” as _id. The new role seems to have a field called “key” instead.

Examples from the repo-browser while trying to debug this issue:

An old role I created a while back:

The new role I just created:

The new role doesn’t seem to work when I try to add users to my admin tool. I see that a few things where changed with the Users app in late Oct., that changed a few things around _id and “key” field amongst other changes: Replace node layer with `lib-auth` calls for Roles and UserStores #82 · enonic/xp-apps@a8f2241 · GitHub

Is it possible that this commit created a bug, so with the code that tries to map principals from admin tools into roles?

This was a lot of data in one rant, if you need more info to examine this closer, please ask :slight_smile:

1 Like
2

The role id is read from the “_name” property of the node. The “_id” of the node should not matter. I tried changing the _id of a role node, and still works for me.

Are you sure your user has the new role?

What do you get, after login in with that user, when you fetch this URL in the browser:
http://localhost:8080/admin/rest/status

3

This is what it looked like after I asked the user to log out and back in, and then go to the rest endpoint. Looks like the user is not getting the principal:

image.png818×508 16.2 KB

Doesn’t really look like the endpoint even thinks the user is logged in?

{
   "version":"6.12.2",
   "build":{
      "hash":"16c41b15a069071f30e3bda9f8bf9ee6d2c166e1",
      "shortHash":"16c41b1",
      "branch":"6.12",
      "timestamp":"2017-10-31T13:58:41+0100"
   },
   "installation":"test",
   "context":{
      "authenticated":true,
      "principals":[
         "group:active-directory:redaktorer-yt-poc",
         "group:active-directory:redaktorer-profilmanual",
         "role:cms.cm.app",
         "role:cms.expert",
         "role:system.admin.login",
         "role:system.authenticated",
         "role:system.everyone",
         "user:active-directory:mankri"
      ]
   }
}
4

I reproduced the issue. It looks like it is a bug.
The problem is not the _id in the role node, but that it was created with the wrong permissions. The role node gets read permissions for “system.everyone” but it should have read permissions for “system.authenticated”.

It was fixed in Users app but after the 6.12 release. The commit you pointed to was actually the fix.

5

Is it possible to replace the fixed Users app somehow, or am I out of luck with creating roles until it gets released together with Enonic XP?

6

Hi Espen

We will try to release a bugfix to 6.12 next week.

7

Ok, I will try to use the node api to hack the roles node, so it starts working for our users in the meanwhile then :slight_smile:

2 Likes
8

If anyone else happens to stumble upon this problem, I basically “patched it” by throwing the following code into the main.js (init file) for my xp app:

var role = node.connect({
    repoId: 'system-repo',
    branch: 'master',
    principals: ["role:system.admin"]
});

role.modify({
    key: "/identity/roles/redirect.management",
    editor: fixPermissions
});

function fixPermissions(node) {
    node._permissions = [
        {
            "principal": "role:system.authenticated",
            "allow": [
                "READ"
            ],
            "deny": []
        },
        {
            "principal": "role:system.admin",
            "allow": [
                "READ",
                "CREATE",
                "MODIFY",
                "DELETE",
                "PUBLISH",
                "READ_PERMISSIONS",
                "WRITE_PERMISSIONS"
            ],
            "deny": []
        }
    ];

    return node;
}
2 Likes