We have moved to GitHub Issues
Created by Jesper Mayntzhusen 19 Mar 2018, 09:43:17 Updated by Callum Whyte 26 Jul 2018, 14:40:44Tags: Gold partner Consider for sprint
Is duplicated by: U4-11507
Your report will have a greater chance of being addressed if you can give us clear steps to reproduce the issue, please answer the following questions in as much detail as possible:
What did you do? *Create a user group with all permissions on but only access to the users section. *Assign a new user to only that group. *Log into that user and create a new user group from it. *Leave all settings as default and click save.
What did you expect to happen? I expected the group to save as normally
What actually happened? I instantly got logged out with the message 'Session timed out.' and the group didn't save.
I can reproduce on 7.9.2 as well.
After further testing I have found this bug also occurs to a user group that has access to all sections and has all permissions enabled.
Our Gold Partner Embrace wants to set their site up so their clients have access to all content sections except Developer and Settings, but they should still be able to create and manage user groups for their content editors.
The following process produces the bug: *Create a user group with all permissions on and access to all sections. *Assign a new user to only that group. *Log into that user and create a new user group from it. *Leave all settings as default and click save. *You get session logout
Why is this a problem?: This means that any agency that wants to create a user group for their clients that should be able to create more usergroups internally will not work.
Pending further tests my guess is that any custom group is unable to create another custom group.
After upgrading from 7.6.11 to 7.10.4 it happens to me as well.
We're experiencing the same problem creating a user group under the "editor" user group.
I have replicated the issue on an instance running 7.10.4 as well.
I've been investigating this issue this morning and have replicated on the latest v7 (v7.11).
It looks like the issue was introduced in v7.7 as part of the new user section - here's the specific change: https://github.com/umbraco/Umbraco-CMS/commit/5afe16ae0e6b5a38d5a936948af3df132ca3c100#diff-70ac9fb4e1b6665d4489123034740a75R34
AuthorizeGroupAccess method checks if the current user is in the user group passed in. In this case, the
AuthorizeGroupAccess is being used for validation before creating the new user group - therefore the user does not have access to the group because it does not exist yet.
You can replicate the same behaviour when removing users from a user group...
The 1st save performs the
AuthorizeGroupAccess which passes (as the user still exists in the user group at this point), the 2nd save fails and redirects to the login page as the user is now not in the user group.
My proposed solutions:
Remove the option to create and edit user groups for any users other than admins - this doesn't exactly fix the problem but it prevents it from occuring ;-)
Only run the
AuthorizeGroupAccess check on user group saves, rather than on creation - this allows for user groups to be saved but still doesn't allow for them to be seen in the backoffice so the same issue exists
Automatically asign the creating user to the user group - this doesn't fix the issue that occurs when removing yourself from a user group
Introduce a new "permission" setting on user groups for "allowed to manage user groups" and adjust the
AuthorizeGroupAccess check to include this. If this is enabled for the user they are allowed to create and edit user groups as currently, if it is not set then the create and edit buttons are hidden in the backoffice
Additionally, I feel the behaviour of redirecting the user back to the login screen is inconsistent with the rest of the backoffice whereby usually a red error message appears instead - see accessing nodes that the user doesn't have permission to for example. The reason the user is redirected is if
false the web API returns a
401 Unauthorized status code which causes the backoffice to redirect the user to the login page (the user is not logged out however). I would suggest changing this to return a
403 Forbidden status code instead to resolve this.
I'm happy to submit a fix providing we can agree on a solution here first :-)
@callumbwhyte Just a very quick reply, we'll need to look into this more deeply before I can give you a better reply:
AuthorizeGroupAccessdoes, but it seems like a security thing we shouldn't bypass (I have not looked at the code or know it's intention)
@sebastiaan Thanks for taking a quick look! Agreed on points #1 and #2.
I suspected it was going to be the case that this should be available to anyone with access to the users section. Restricting it to only allow editing of user groups that the user currently belongs to is where this falls down currently...
Perhaps the logic could be adjusted as such:
This would still mean that if a user creates a new user group but does not add themself as a user of that group then they would not be able to edit it... But maybe that's okay? We would need to consider what happens once a new user group is created but the user doesn't have permission to view / edit it - currently we would just send them to the login screen, which naturally isn't great UX.
Will await someone on HQ's side to look into this a bit deeper :-)
Backwards Compatible: True
Affected versions: 7.7.0, 7.8.0, 7.7.1, 7.7.2, 7.7.3, 7.7.4, 7.7.5, 7.7.6, 7.7.7, 7.7.8, 7.9.0, 7.7.9, 7.7.10, 7.7.11, 7.8.1, 7.7.12, 7.7.13, 7.10.0, 7.9.1, 7.9.2, 7.9.3, 7.11.0, 7.10.1, 7.10.2, 7.9.4, 7.10.3, 7.8.2, 7.9.5, 7.10.4, 7.8.3, 7.9.6, 7.10.5, 7.12.0, 7.11.1, 7.11.2
Due in version: