More secure email change

GitHub PR 2453 was recently merged. This contains a token mechanism that we can use for one-time links. It would be great to use this for secure email changes.

Update: In order to use this code, we must update the BOINC webcode in html/.

BOINC webcode now available on both sites. Please go ahead...

Just a status update: I'm working on this code for a more secure email change. It mimics upstream UX: User changes email, s/he receives two emails at both old and new addresses, the old address contains a link with a token that allows for reverting the email address change. Users may only change their email once every 7 days.

My understanding is that this isn't a GDPR 'requirement' , so it may not be merged until after this week.

That understanding is correct. I think it "just" ties into the password reset improvement which depends on this to be secure.

Meeting summary 2018-06-21: The problem that I identified above is a BOINC upstream problem: See GitHub issue 2565.

Update: GitHub PR 2566 created to change the Drupal Web site email change workflow to match that of BOINC upstream.

Thanks to Tristan for merging the PR.

Deployment: This should be a straightforward merge of the code.

Deployed on both sites, please test.

I missed a bug in my alpha testing. But it's a quick one-line fix. Coule Tristan Olive merge it soon?

GitHub PR 2599

Bug: I used the drupal 'uid' instead of the BOINC 'id' in when loading the user from the BOINC project database, which obviously is not what is suppose to happen.

Update: Another GitHub PR 2601 created.

Bug/feature: If a user changes his/her email via an AM: the am_set_info.php RPC triggers the upstream BOINC code to send the two emails. The recovery URL path is different than the Drupal recovery URL path, and will not work. This PR adds a 'redirect' to allow the recovery URL to work correctly.

I changed my addresses on albert and einstein: on albert I received no emails, on einstein I received two, one each to each address (old and new). The einstein mail to the new address contained timestamps that where both base on the unix epoch 0, which is clearly wrong:

Your email address was changed from AAA to BBB on January 1, 1970 at 0:00 UTC. You will not be able to change your email address until January 8, 1970 at 0:00 UTC. If you need to reverse this change, please look for an email send to the email address: AAA.

Annoyingly, I can not reproduce this. On albert, when I changed my email address I received the following email, with the correct times.

Your email address was changed from A@B.C to X@Y.Z 
on July 16, 2018 at 14:47 UTC. You will not be able to change your email  
address until July 23, 2018 at 14:47 UTC. If you need to reverse this change,  
please look for an email send to the email address: A@B.C.

(PRs merged)

FYI, I just checked again: the timestamps were the same on einstein and albert. Sigh

PRs deployed on both sites, please test.

Two things

1) I tested the new PR code, they are working as expected.

2) Your problem is a 'feature' and not a bug! It's because your admin account has the ability to 'administer users'. See the ternary statement in the code. The reason for this is because admins may change another user's email address. We use the same (Drupal) form to change the email as any other user. Thus if this ternary statement did not exist, then the seven day wait period would be set when we changed a user's email for him/her; and there may be reasons we don't want that. My reasoning is whenever I typically change a user's email, it is usually a temporary change: the user wants to change it right away to something else.

It should be said if an admin changes a user's email, the user still receives the two email messages from the projects as normal.

But the result of this code is what you saw: when you change your OWN email address, the timestamp is set to it's previous value, which is zero; hence Jan 1 1970. Likewise when I changed my email address, I was using my non-admin test account.

So if understand this correctly, there's nothing to do here anymore and the issue can be closed?

Alternatively, we could think about blocking that confusing part of the email message for those affected...?

Alternatively, we could think about blocking that confusing part of the email message for those affected...?

This is yet another bug that we should fix. Fortunately this should be small and simple and I should be able to put together a PR very soon. The bug is that when the admin changes the email address of someone, the times in the email are incorrect: like the ones you received. I'll change the code a bit, and as you suggest remove the part of the message that is confusing.

Update: GitHub PR 2609 contains the changes that should fix this problem. Hopefully after this fix, we can close the issue ticket.

Deployment: Lastest PR - a simple merging of new code.

Deployed on both sites (days/weeks ago, untested)...

Tested on albert: email message no longer contains time- only when an admin changes an email address. For any additional new problems, we should create a new ticket.