do not allow to modify exsiting username #3531
Conversation
fanjinfei
force-pushed
the
ckanmaster
branch
4 times, most recently
from
686af57
to
f42789d
Compare
|
ready for review |
ckan/controllers/user.py
Outdated
| @@ -349,6 +349,14 @@ def _save_edit(self, id, context): | |||
|
|
|||
| email_changed = data_dict['email'] != c.userobj.email | |||
|
|
|||
| if id != data_dict['name']: | |||
There was a problem hiding this comment.
Shouldn't this check be done at the validation level? Otherwise the name will be able to be changed via the API
|
On second thoughts I'm not too sure about this. For instance when you get an invite to an organization (via email) you get a user name assigned based on your email plus some random characters, eg Another use case is if someone leaves the organization but you still want to keep using the CKAN user changing its name. I think it's a useful feature and if there are auth implications somewhere related to changing the name we should fix those. |
|
invites shouldn't be creating users, they should just send a URL that can be used to create a user already added to an org |
|
If changing usernames is genuinely useful we could live with just being able to override the schema so we can disable it on our site cleanly. That's not something we can do right now. |
do not allow to modify exsiting username
|
Happy to provide the related reasoning behind this security enhancement - is there a CKAN core team email I can interact with? |
|
Hello Adrià and crew, Could you please advise the security reason why the username editing is now been disabled? In our organisation (gov), we use a distributed publishing model where each dept (~40) manages its own publishers (~400). To keep the publisher names anonymous from the public, we use "agency-acronym_publisher_123" username pattern (e.g. transport_publisher_123). We do maintain an internal registry with the publisher's details etc. However, like every other gov, we do have dept name changes after elections/new gov, where we need to update the usernames to reflect the name changes. With this feature now been disabled, it is a massive headache for us as we have no other option than creating new user account and delete old ones. This is very time consuming and also publishers will lose history, follows etc. I do appreciate you may have valid reasons behind this change, however, is it possible for the sysadmin or on the production.ini to set the flag if the username is editable or not instead of bake it to the code? Happy to hear your suggestions too. Thank you and appreciate the team's contribution to CKAN. Kind regards, |
Fixes #
Proposed fixes:
Features:
Please [X] all the boxes above that apply