Confirmation of change of e-Mail-address

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

in case of self-registration with e-mail confirmation users receive an e-mail for account activation.

Once the account has been activated the e-mail address can be changed in the personal profile without any further required confirmation. This could enable users to register, confirm their e-mail and afterwards use the e-mail address of another person. Thereby, the other person would receive messages from ILIAS without having consented to it.

We also assume that this behaviour is not compliant with the GDPR.

Currently, users are logged out on the change of their address. But this does not asure, that the user is in posession of the new email address. So the current functionality does not prevent the basic problem of this Request.

2 Conceptual Summary

Provided that confirmation of e-mail address is activated in the registration, we suggest that the change of an e-Mail address should also require a confirmation via a confirmation link.

Only if the user's account is a local account, self-registration is active and if the registration requires a confirmation via email, the change of an email address should be verified.

Process: When a user enters a new email address and clicks "save",

• the user shoud be infromed that the change has to be confirmed and about the timeout (probabliy popup/modal)
• a confirmation link should be generated and sent to the new email address
• A mail is sent to the old email address about the change request
• (No change to standard process now: The user is logged out and has to login again)
• as long as the user does not confirm the new address, the old addres should remain active
• as soon as the user confirms the new address, the old address is discarded an the new address is used
• there should be a timeout for the confirmation. As a first approach, the timeout value set in the registration can be used here. The timeout should start as soon as the user saves the new address. Alternatively the timeout can start with the logout which currently is mandatory when changing email adresses
• as long as the change is pending,there shoud be a message in the user profile that informs the user about the pending change (info-message or similar)
• the email address listed in the profile should always reflect the currently used address (old address until confirmation, new address from confirmation)
• if the change is not confirmed within the timneout period, the new emailaddress is deleted, messages in the userprofile disappear, and an email shoud be sent to the old address that the change was discarded.
• To be discussed: Optionally we could have an error message in the profile about the discarded change whis is displayed once when the user opens the profile (or remains until the profile is saved)

In other cases (e.g. email address is provided via LDAP, self registration without confirmation) there should be no confirmation of address changes.

3 User Interface Modifications

3.1 List of Affected Views

• The personal profile page needs an additional element that informs the user about the pending change
• Information for the user about the process and the timeout, if the confirmation is triggered

3.2 User Interface Details

If the user initiates the change of an e-mail-address an e-mail should be sent which corresponds to the e-mail confirmation during the registration process.

Modal, popup or new page, that informs the user about the confirmation process and the timout for the confirmation

If the timeout is not taken from the registration process, a new setting for the timeout of the confirmaton would be needed. We would prefer to use the timeout value for the registration-confirmation, since the email-confirmation is only usef if the self-registration requires a confirmation

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

None

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

No new data will be processed.

This feature is intended to avoid privacy violations.

6 Security

No, it doesn't.

7 Contact

• Author of the Request: Elena Erkeling
  
• Maintainer: Stephan Kergomard
  
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• DHBW

9 Discussion

JourFixe, ILIAS [jourfixe], 10 JUN 2024: We highly appreciate this suggestion and schedule the feature for ILIAS 10.

10 Implementation

The feature was implemented as described above.

Test Cases

Test cases completed at 20 AUG 2024 by Kergomard, Stephan [skergomard]

• c76512: Eigene Email-Adresse ändern

Privacy

Information in privacy.md of component: no change required

Approval

Approved at 2024-09-30 by Jackisch, Ingo [jackisch].