Removing email addresses can cause mismatch with Canonical SSO

[Stuart Bishop]

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.

[Curtis Hovey (sinzui)]

PersonEditEmailsView.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

[Henning Eggers (henninge)]

I am not sure if this is the same bug that this user is hitting:

<qtheuret> I had two email addresses on my account settings and I had remove one yesterday
<qtheuret> today, when I try to connect to Launchpad, I have this error message : Sorry, something just went wrong in Launchpad Login Service.
<qtheuret> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
<qtheuret> (Error ID: 1965canistellaunchpad7)
<henninge> qtheuret: what is the account name?
<qtheuret> quentin-theuret
<henninge> qtheuret: I assume that the adderess you removed was the one you originally used for registration?
<qtheuret> yes
<qtheuret> but I have add a second address because I not use the first address
<henninge> qtheuret: did you re-enter your credentials when you logged in today?
<qtheuret> yes, I re-entered my credentials and it's at this moment that the error message is displayed
<henninge> qtheuret: can you access this? https://login.launchpad.net/
<qtheuret> It's on https://login.launchpad.net/ that the message appears
<henninge> did you use the old or the new address for login in?
<qtheuret> both and no success
<qtheuret> on other PC with a valid cookie on Launchpad, I'm connected without re-enter credentials

[Martin Pool (mbp)]

also https://bugs.launchpad.net/moin-openid/+bug/342431 (perhaps only vaguely related)

[Selene ToyKeeper (toykeeper)]

Another dupe: https://bugs.launchpad.net/canonical-identity-provider/+bug/812761

Users seem to find it quite confusing in general that SSO and LP use two different sets of email addresses. It's not inherently a difficult concept, but users seem to have the wrong model in their head and so they end up breaking their accounts by doing things which seem like they should work. I think it could probably be fixed or at least improved by either integrating LP and SSO a bit more, or by making the separation much more explicit. From the dupe I just linked, here are some ideas:

  - Store all email addresses in SSO, and reload into LP on each login. This may require additional openID extensions, and code to handle odd cases in LP (such as an address being deleted when it was in use for a mailing list). It may also cause issues if a user changes their SSO addresses but doesn't log in to LP to update it.

  - Separate LP and SSO even more, to make it clear to users that the two are not tightly integrated or closely related. One approach might be to get rid of login.launchpad.net and add UI bits in both LP and SSO to point out that they are different systems which do not share a common set of addresses.

Any other ideas?

[Anony Mouz (anonymouz-s)]

I have seen quite a few bug entries related to this bug. It seems that there could be a simple solution in theory anyways. I would suggest not using the primary email address as the account anchor, which seems to be what is happening. It would seem like a better solution to let the user pick a random string of text/numbers to use as a login ID and tie that to the user account GUID or similar. This way, the users email address doesn't really matter that much, except for lost passwords, etc.

[Forest (foresto)]

> Perhaps instead of removing email addresses we should instead
> flag them as OLD and hide them from display?

That wouldn't work out so well for someone who changes their email address because they have switched ISPs and no longer have access to the old address, especially if someone else takes over the old address. (I ought to know; my primary email address once belonged to someone else, and I occasionally get messages that were intended for them.)

[Wes (wesinator)]

I encountered this problem when I changed my Ubuntu One login email address to a new address and deleted my previous address.

The email address in Launchpad was not updated with the new address, so I was still receiving bug mail at my old address until I manually changed / removed the email address in Launchpad also.

I expected changes in Ubuntu1 SSO to be automatically applied to the associated Launchpad account.