Project

General

Profile

Actions

Feature #33216

open

/my/account: Prevent users from changing their Email [redmine 4.1.0 stable]

Added by James Barrante almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Accounts / authentication
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

An organization's policy requires users not be able to change their Redmine e-mail address.

(Extra background/scenario info: User registration, Project and Role assignment is done by a script which also uses the autologin cookie feature of Redmine: User clicks a link from an Intranet page, that script handles above user creation tasks (if user doesn't exist yet) and logs him/her into Redmine, without ever requiring them to enter a password for Redmine. Logout is done by having Apache redirect the "/logout" script to some different URL on the Intranet which also clears the Redmine session cookies.) So far, we are very happy and thankful to all Redmine Contributors.

While it is possible to change the number of extra e-mail addresses from 5 (default) to 0 [Administration > Settings > Users > Maxmimum number of additional email addresses], it still means that (under /my/account) any user logged in is able to change their e-mail address, unless the e-mail address is already taken by someone else in the system.

Having an Administration setting to "lock" only the Email address of an account would be great. It could help enforce policy of only using the organization's e-mail addresses.

From debug production.log, when a user updates his Email:

EmailAddress Update (0.2ms) UPDATE `email_addresses` SET `address` = '[redacted]', `updated_on` = '2020-03-29 18:55:59' WHERE `email_addresses`.`id` = 2

Hacking I tried:
  • As a Ruby novice, I really am having a rough time finding my way through the code. Thanks to MVC, I don't believe it's as easy as just commenting out a line of code responsible for triggering the above SQL? Any pointer would be greatly appreciated.
  • Maybe app/controllers/email_addresses_controller.rb would be a place to start, but I'm not sure.
Feature request:
  • Add a Checkbox under Administration > Settings > Users: Allow users to change their email addresses, checked by default
"Workarounds":
  • Apache Rewrite Rule to block access to /my/account altogether. Easy to implement, radical and effective, but not very friendly, as some useful Preferences (Time zone, UI Language) will be unavailable to users.
  • Cronjob to replay any changed e-mail addresses to the MySQL database. Doesn't feel right.
  • MySQL trigger to roll back any UPDATE statement to the `email_addresses` table. Hackish but better than cron; will likely break once a heavier DB Migrate script runs after updating Redmine.

Related issues

Related to Redmine - Feature #3369: Allowed/Disallowed email domains settings to restrict users' email addressesClosedGo MAEDA2009-05-16

Actions
Actions #1

Updated by Go MAEDA almost 4 years ago

  • Related to Feature #3369: Allowed/Disallowed email domains settings to restrict users' email addresses added
Actions #2

Updated by Go MAEDA almost 4 years ago

James Barrante wrote:

Having an Administration setting to "lock" only the Email address of an account would be great. It could help enforce policy of only using the organization's e-mail addresses.

In #3369, a feature is proposed that would allow users to only use email addresses from domains that are pre-allowed.

The feature is different from the one proposed here, but I think your request "enforce policy of only using the organization's e-mail addresses" can be achieved.

Would it be helpful to you if #3369 was implemented?

Actions #3

Updated by James Barrante almost 4 years ago

Thank you, Go MAEDA.

Would it be helpful to you if #3369 was implemented?

In certain ways, yes. It could help in a scenario where only one organization (or a small set thereof) is served. It would not prevent address changes in the form of <> to <>, if both domains are in the whitelist. But it could certainly improve things for the outlined scenario.

However, please still consider a lockdown on the email address.

Actions

Also available in: Atom PDF