Can't validate additional email address, token link gives 404

Bug #1693375 reported by Hajo Möller
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Invalid
Undecided
Unassigned

Bug Description

I added a second email address to my account, but following the verification link shows my browser's 404 page:

This login.launchpad.net page can’t be found

No webpage was found for the web address: https://login.launchpad.net/SOME-HAS/token/ANOTHER-HASH/+newemail/MY-ADDITIONAL-EMAIL
HTTP ERROR 404

Revision history for this message
Daniel Manrique (roadmr) wrote :

Hello,

Did you by any chance use a different browser or device to click on the link, from the one you initially logged in from?

Can you try logging into Ubuntu SSO, clicking on the "verify" button on your second e-mail address, and then paste the link on the same browser window where you logged into SSO initially? This should ensure the session is the same one the system expects and allow you to validate the address.

I'd still like to know the answer to my question above since that's the only situation where we've observed this behavior.

Thanks!

Changed in canonical-identity-provider:
status: New → Incomplete
Revision history for this message
Hajo Möller (dasjoe) wrote :

Hi,

I successfully verified the second e-mail address by following the procedure you described.

However, I noticed the verification link's format changed.

The old verification link:
https://login.launchpad.net/d7jEeZt0pSrYTvms/token/dFYdB64HQdWmdT6kxKtZ/+newemail/MY-ADDITIONAL-EMAIL

The new, working one:
https://login.launchpad.net/token/RvXgwkjcLKFGcYZJwrWF/+newemail/MY-ADDITIONAL-EMAIL

Revision history for this message
Eric Stith (estith) wrote :

I'm seeing the same behavior. The first links sent out lead to a 404, the later one worked.

Daniel Manrique (roadmr)
Changed in canonical-identity-provider:
status: Incomplete → Invalid
Revision history for this message
R (jkjl) wrote :

I had this issue at registration. The problem was using a different browser session (Incognito mode).

Where is the assumption that people will necessarily use the same browser session to click on the validation link is coming from? Could that at least show an explicit error rather than showing a generic 404 page?

Revision history for this message
Daniel Manrique (roadmr) wrote :

This only happens when you're trying to register as part of logging in to another site (relying party). You can tell if your validation link has two tokens (the alphanumeric random-looking things) instead of just one.

So:

This works:

1- Go to login.ubuntu.com on browser/device A, to register.
2- Obtain your validation link on browser/device B and click on it
3- Validate
4- Now, try to go to e.g. dashboard.snapcraft.io and authenticate there with the existing credentials

This does not:
1- Go to dashboard.snapcraft.io on browser/device A and click on "sign in or register"
2- Since you didn't have an account, start a new registration.
3- Obtain your validation link on browser/device B and click on it

^^ This won't work because in order to send you back to dashboard.snapcraft.io after you've registered and validated your e-mail address, the data stored in the session cookies of device A is required. If you try to open the link on browser/device B, the session containing the data linking back to the relying party (dashboard.snapcraft.io in this case) is not present, so the site does not know where to send you, and out of caution, it 404s instead, assuming you tried to steal the link from an intercepted e-mail or something.

Also as a comment, We have had the *opposite* bug filed: when you create and validate an account as part of signing into an RP, if you don't get sent back to the RP, people get confused. So the above is the behavior our users have requested, but for the reasons I mention above, it will only work if you use the same device/browser session to start the process and to access the validation link.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.