[xwiki-devs] [Proposal] Fix inconsistencies in access to the change password feature
Hi devs, I would like to fix the current inconsistencies in the way the change password feature is implemented. Actually, to be able to change a password, you need to be able to save the document storing the XWikiUsers XObject. So edit right on the user profile is just what you require, but, if you want to use the "change password" feature implemented in passwd.vm, you need: - either being on your own profile or having global (!) admin right, just to see the "Change password" button - either being on your own profile or having (local) admin right on this profile, just to be able to use passwd.vm This seems to me really inconsistant, since these protections implemented in the UI part are either annoying or a false impression of security. So, I propose to simplify this by only checking the real requirements, which means only checking edit right on the user document ? WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 Do not prohibit what you cannot prevent. Caleb Denis Gervalle wrote:
Hi devs,
I would like to fix the current inconsistencies in the way the change password feature is implemented.
Actually, to be able to change a password, you need to be able to save the document storing the XWikiUsers XObject. So edit right on the user profile is just what you require, but, if you want to use the "change password" feature implemented in passwd.vm, you need: - either being on your own profile or having global (!) admin right, just to see the "Change password" button - either being on your own profile or having (local) admin right on this profile, just to be able to use passwd.vm
This seems to me really inconsistant, since these protections implemented in the UI part are either annoying or a false impression of security. So, I propose to simplify this by only checking the real requirements, which means only checking edit right on the user document ?
WDYT ?
Denis
On 05/03/2010 04:34 PM, Denis Gervalle wrote:
Hi devs,
I would like to fix the current inconsistencies in the way the change password feature is implemented.
Actually, to be able to change a password, you need to be able to save the document storing the XWikiUsers XObject. So edit right on the user profile is just what you require, but, if you want to use the "change password" feature implemented in passwd.vm, you need: - either being on your own profile or having global (!) admin right, just to see the "Change password" button - either being on your own profile or having (local) admin right on this profile, just to be able to use passwd.vm
This seems to me really inconsistant, since these protections implemented in the UI part are either annoying or a false impression of security. So, I propose to simplify this by only checking the real requirements, which means only checking edit right on the user document ?
WDYT ?
I don't like it so much. Even if the change is possible for random users, I wouldn't like them to see a big "change this user's password" button when looking at my profile. Most users of a wiki don't know how to change a password through the object editor, but they do know how to click on a link. It's not about security, it's about ease of access to this dangerous feature. Anyway, in most wikis only the owner and the admins have edit right on a profile, so it's the same thing in the end. +1 for fixing the inconsistency in local/global admin rights. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Mon, May 3, 2010 at 20:23, Sergiu Dumitriu <[email protected]> wrote:
On 05/03/2010 04:34 PM, Denis Gervalle wrote:
Hi devs,
I would like to fix the current inconsistencies in the way the change password feature is implemented.
Actually, to be able to change a password, you need to be able to save the document storing the XWikiUsers XObject. So edit right on the user profile is just what you require, but, if you want to use the "change password" feature implemented in passwd.vm, you need: - either being on your own profile or having global (!) admin right, just to see the "Change password" button - either being on your own profile or having (local) admin right on this profile, just to be able to use passwd.vm
This seems to me really inconsistant, since these protections implemented in the UI part are either annoying or a false impression of security. So, I propose to simplify this by only checking the real requirements, which means only checking edit right on the user document ?
WDYT ?
I don't like it so much. Even if the change is possible for random users, I wouldn't like them to see a big "change this user's password" button when looking at my profile. Most users of a wiki don't know how to change a password through the object editor, but they do know how to click on a link.
It's not about security, it's about ease of access to this dangerous feature.
My users, those with extended rights (but not global admin right which is a dangerous feature), call this one a useful feature, since their user, that are even more ignorant of computer, always forget their passwords. Due to XWIKI-4998 and also their misunderstanding of computers, their users does not found or cannot use the forget password feature and call them. So for me this is a feature, but I agree, we should change the button label to clearly state that it change this user password.
Anyway, in most wikis only the owner and the admins have edit right on a profile, so it's the same thing in the end.
+1 for fixing the inconsistency in local/global admin rights.
If you talk about setting it to local admin right (in place of edit as I propose), I would agree since I can provide admin right on user profile to these extended users, but this introduce additional issues: - the current right editor does not display admin right anymore on documents - we should also secure the same change password in the object editor by also checking admin right This is why I have proposed edit right to be checked, and consider that a use case where the a user can change the name of another one but not its password is really unusual. Anyway, this change would deserve a clear explanation in the release note. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (3)
-
Caleb James DeLisle -
Denis Gervalle -
Sergiu Dumitriu