Removing email addresses can cause mismatch with Canonical SSO
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical SSO provider |
Confirmed
|
High
|
Unassigned | ||
Launchpad itself |
Triaged
|
High
|
Unassigned |
Bug Description
Users can remove the email address they use to login from their Launchpad account.
A valid use case for this is people changing <email address hidden> to foo#<email address hidden> to help with email filtering.
This is not good, as Person records with an associated email address can get created by automated processes such as translation imports.
Previously, we didn't notice this - the user would end up logging into a different Launchpad account to the one that owned their authentication email address, but they didn't care because they were logged into the Launchpad account they where expecting to log into.
Now, the authentication code repairs the links as best it can to cope with drift in the Canonical SSO database, such as people changing their email addresses on that system. So the user logs into Launchpad, and Launchpad notices that the OpenId Identity and EmailAddress are linked to different accounts and fixes this the only way it can - by changing the account the OpenId Identity is linked to. The user is now logged into a different Launchpad person than they were expecting, although it has their email address and probably their displayname.
The user currently has to fix this by merging the Person records.
Perhaps we should block people removing the email address they are currently using to authenticate, because doing so will shoot them in the foot? Users can still add new email addresses and set them as preferred, although they might not believe that Launchpad only uses the preferred email address (and when we have bounce processing, we might fall back to other registered email addresses if the preferred starts failing).
Perhaps instead of removing email addresses we should instead flag them as OLD and hide them from display? The status already exists, and out code already ensures it only uses email addresses that are VALID or PREFERRED to ensure we don't trust NEW email addresses. Adding a new email address would become trickier though if it happens to be linked to another account with OLD status.
Changed in launchpad-registry: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → series-future |
tags: | added: openid |
Changed in launchpad: | |
status: | Triaged → Confirmed |
Changed in launchpad: | |
status: | Confirmed → Triaged |
Changed in canonical-identity-provider: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in canonical-identity-provider: | |
status: | Confirmed → Incomplete |
status: | Incomplete → New |
Changed in launchpad: | |
status: | Triaged → Confirmed |
status: | Confirmed → Incomplete |
status: | Incomplete → Opinion |
Changed in canonical-identity-provider: | |
status: | New → Confirmed |
Changed in launchpad: | |
status: | Opinion → Incomplete |
Changed in canonical-identity-provider: | |
status: | Confirmed → Incomplete |
Changed in launchpad: | |
status: | Incomplete → Confirmed |
Changed in canonical-identity-provider: | |
status: | Incomplete → New |
Changed in launchpad: | |
status: | Confirmed → Fix Committed |
Changed in canonical-identity-provider: | |
status: | New → Fix Released |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
Changed in canonical-identity-provider: | |
status: | Fix Released → Confirmed |
Changed in launchpad: | |
status: | Fix Released → Triaged |
PersonEditEmail sView.action_ remove_ validated( ) is the method deleting the email address. I thought it was already marking the address as OLD. The view is already hiding addresses form display because it selects by status.
How do we know what email addresses are being used to authenticate? I believe account reactivate is broken because when the user logs into Lp via SSO, We do not know what email to make preferred.
We could mark the address as OLD. On authentication (with the passed email address), we could check if the email address in UNVALIDATED/OLD and acknowledge to the user that he logged in with an unexpected address. If there is no preferred address, we could use the one passed by SSO. If the address is OLD and belongs to another account, I think we have two options: a) stop and ask the user to contact an admin, or b) transfer the email address to the other account quietly