[MAGNOLIA-3728] Users created without permission to change own properties Created: 07/Jun/11  Updated: 19/Dec/16  Resolved: 04/Aug/15

Status: Closed
Project: Magnolia
Component/s: admininterface, security
Affects Version/s: 4.4.3, 4.4.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Marc Werlen, Netcetera Assignee: Philipp Bärfuss
Resolution: Outdated Votes: 4
Labels: admincentral
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

local dev env, enterprise edition, windows
productive env, enterprise edition, linux
http://demoauthor.magnolia-cms.com


Attachments: XML File config.modules.adminInterface.trees.usersAdmin.xml     XML File users.admin.untitled.xml     XML File users.admin.user1.xml    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When creating new User in the admincentral (Menu 'Security'=>'Users', then invoke 'New user'), user is created as untitled, which seems correct.

According to forum thread
http://forum.magnolia-cms.com/forum/thread.html?threadId=30ce8ee0-9c9f-42c1-b02f-3a668bb96a59&page=1
then a node 'acl_users' should be created under the new users node, allowing to change own properties.

The user is created, but no 'acl_users' node is included.
Debugging does not showing MgnlUserManager.createUser(String, String) being invoked.

Renaming the user to 'user1' doesn't add the missing 'acl_users' node, according to export-XML.
Adding groups (editor) also doesn't fix the problem.

When logging-in as the user1 and editing own settings, the dialog is empty when loaded, save leads to empty page.
On loading the dialog, the logs show an error:
2011-06-07 10:36:38,473 ERROR fo.magnolia.module.admininterface.DialogMVCHandler: can't read content to edit
info.magnolia.cms.security.AccessDeniedException: User not allowed to Read path [/admin/user1]
at info.magnolia.cms.core.Access.isGranted(Access.java:64)
at info.magnolia.cms.core.DefaultContent.<init>(DefaultContent.java:117)
at info.magnolia.cms.core.DefaultHierarchyManager.getContent(DefaultHierarchyManager.java:236)

after submit a npe is logged, caused by the node not read previously to the password dialog control:
2011-06-07 10:36:38,488 ERROR info.magnolia.cms.servlets.MVCServletHandlerImpl : can't call command: save
java.lang.NullPointerException
at info.magnolia.cms.gui.dialog.DialogPassword.validate(DialogPassword.java:98)
at info.magnolia.cms.gui.dialog.DialogControlImpl.validate(DialogControlImpl.java:620)

Can be reproduced perfectly on current demoauthor-instance (althought the 'eric' demo-user is able to change own properties).



 Comments   
Comment by Danilo Ghirardelli [ 10/Aug/11 ]

This is quite annoying for users... My workaroud for the problem is to add a role with permission to read/write the users repository. Not exactly secure but at least users can change their language or password.

Comment by Marco Glur [ 22/Nov/11 ]

Is there any work going on or is it quasi rejected to fix this? The work around won't work for us due to our security demands. Users must not be able to add themselves new roles or groups.

Comment by Marco Glur [ 28/Nov/11 ]

I found a possible solution to the problem, when looking at differences between adminInterface tree definitions:

  • users tree class: info.magnolia.module.admininterface.trees.UsersTreeHandler
  • usersAdmin by default is of class info.magnolia.module.admininterface.AdminTreeMVCHandler

Setting the class accordingly for the tree usersAdmin seems to fix the problem.

Now I'm not quite sure if there is any impacts caused by this tree handler class, or if there is a good reason it is not set to UsersTreeHandler.
Maybe it is just accidentally?

Fixed and exported file attached.

Comment by Michael Mühlebach [ 04/Aug/15 ]

We're closing this issue as outdated as it was reported for 4.4.x or earlier versions which are no longer supported. Don't hesitate to reopen or create a new ticket in case this is still relevant and you'll experience it on 4.5.x or later versions.

Generated at Mon Feb 12 03:49:07 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.