Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assigning access to a role for a restricted folder, disables restriction to that folder #197

Open
togis opened this issue Oct 6, 2023 · 5 comments · May be fixed by #200
Open

Assigning access to a role for a restricted folder, disables restriction to that folder #197

togis opened this issue Oct 6, 2023 · 5 comments · May be fixed by #200
Assignees

Comments

@togis
Copy link
Contributor

togis commented Oct 6, 2023

Hi everybody,

I just experienced a strange behavior assigning access roles while managing subscribers in groups.

Lets say we have several folders e.g. folder1, folder2, folder3 that are accessable for certain user roles like group1, group2, group3. The roles get assigned to the users like group1 > user1, group2 > user2, group3 > user3 and everything works fine.

Then I add a new restricted folder4 and create a new subscriber role (group4) with access to the new folder4. After assigning the access rights to the new role, folder4 is accassable to all logged in users not only to group4.
When I then safe folder4 without changing anything, everything works fine again.

To me it looks like the access rights get mixed up after assigning rights to a role and then everything get's in order again after safing the folder.
Any ideas where this might come from?

Thanks;
Tobias

@drfho
Copy link
Contributor

drfho commented Oct 10, 2023

@togis
Thank you for the detailed desciption: I tried to reproduce it.
Actually I cannot confirm that folder saving changes a folder's permissions. You can analyse all permissions & roles with /manage_access

Please take into account::

  1. the role should added to the user at root/content level, even if the permission is in lower folders, so that user is "group1" anywhere.
  2. if user is "Subscriber" any "restrictedview" node is visible.

SCREEN: /manage_access allows inspection of the permission details
user_permissions

@togis
Copy link
Contributor Author

togis commented Oct 12, 2023

@drfho: thank you for looking into the problem and clarifiaction of functionality.

... Actually I cannot confirm that folder saving changes a folder's permissions. ...

The problem just occures when I add permissons to a new role. Saving a folder actually fixes the problem. I checked manage_access and also don't see any changes in the folder permissons after saving the folder.

1. the role should added to the user at root/content level, even if the permission is in lower folders, so that user is "group1" anywhere.

yes, I created all users on the root level and assigned them to their groups. The access rights are then managed in the respective group.

2. if user is "Subscriber" any "restrictedview" node is visible.

Yes, the users will only assigned to their groups and wil have no other access rights.

Can you please check again in the following order:

add folder1 (restricted)
add role "group1"
assign subscriber rights for folder1 to group1
add user1 and assign role group1

login with user1

then:

add folder2 (restricted)
add role "group2"
assign subscriber rights for folder2 to group2 << from this point on user1 can access folder2
add user2 and assign role group2

logout user1 and login user2 and user2 can access only folder2. Logout again and login user1 and user1 can still access both folders.

Now save folder2 and user1 can't access it anymore.

If you can't reproduce this behavior it might be something in my setup. If you like I can give you access to my test enviroment so you can reproduce it here.

@togis
Copy link
Contributor Author

togis commented Oct 13, 2023

@drfho: I got more information:

I looked at the folder2 persmisson of user1 / group1 with subscriber permissions to folder 1 only.

When looking at the permissions of user1 in folder2, it looks like this:
Bildschirmfoto am 2023-10-13 um 12 20 43

Now I assign subscriber permissons to group2 for folder2 and then the permissons of user1 look like this:
Bildschirmfoto am 2023-10-13 um 12 20 51

So after assigning subscription permissions for folder2 to group2, user1 also get's View permissons to folder2.
Saving folder2 then fixes the permissons and everything works like it should.

FYI: I also tested assigning roles to users and this does not mess with the permissons.

@drfho
Copy link
Contributor

drfho commented Oct 13, 2023

@togis
You are right! Many thanks for the 2nd attempt.
Now, I understand the problem and can reproduce it. Not easy to analyse/debug. The behaviour is the result of two aspects:

  1. the ZMSSubscriber-like role_def contains the fixed permissions:
'ZMSSubscriber':['Access contents information', 'View']

,'ZMSSubscriber':['Access contents information', 'View']

  1. When declaring a new "group" with that role_def the linked node initially systematically gets that prototypical permission-set ['Access contents information', 'View'] due to AccessableContainer.synchronizeRolesAccess() (means for anyone besides Anonymous because node is restricted).

# Grant View permission to Authenticated.
for i in [['Authenticated',['View']]]:
role = i[0]
permissions = i[1]
role_permissions = [x['name'] for x in self.permissionsOfRole(role) if x['selected'] == 'SELECTED']
permissions = standard.concat_list(permissions, role_permissions)
self.manage_role(role_to_manage=role, permissions=permissions)

groups_permissions

Discussion:
I suppose when the standard permission is added by group-adding to the node it cannot "foresee" ex-ante what kind of other roles/permission will be added. Of course this is "just" a logical problem; to solve it ex-post - as now - seems to be logically easier ;-)

As a quick solution I would recomment to define the roles first and restrict the nodes as a second step. Then everything should be fine (corresponding to your observation, that the node's permissions are corrected after saving).

Conclusion:
As we spotted the problem now in the code I kindly invite you to suggest a pull request for further approaches.

Looking forward
fh

@drfho
Copy link
Contributor

drfho commented Oct 18, 2023

Hello @togis ,
maybe you can try this change:
PR: https://github.com/zms-publishing/ZMS/pull/200/files
Branch: https://github.com/zms-publishing/ZMS/tree/fb_197
Please give a feedback if it works as expected.
Thanks
fh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants