1072267 - Cannot start marketplace from Firefox Accounts verification confirmation page

Status: RESOLVED FIXED

(Cloud Services :: Server: Firefox Accounts, defect, P3)

Description

[Victor Carciu]

Prerequisites:
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

Steps to reproduce:
1.Open MP-dev and try to sign up via FxA
2.Open the verification email and press the Verify button
3.From Account verification confirmation page, click the MP-dev link

Expected results:
MP-dev is successfully opened

Actual results:
Users are redirected to https://marketplace-dev.allizom.org/fxa-authorize?error=3005 and the MP is never opened.

Please see screencast for this bug : http://screencast.com/t/COox8ajhAp

Comment 1

[Andy McKay]

Not sure what the error=3005 is about.

Comment 2

[Allen Short [:ashort]]

My investigation indicates that the error=3005 parameter gets passed on all but the first click of the link from the verification confirmation page.

The link goes to the oauth callback url for Marketplace. It's currently written to assume that it will be accessed from the popup window we use for login, so it doesn't do anything if the link is clicked in the verification confirmation page shown from clicking the link in the email. However... clicking the 'continue' link in the popup after verifying the email does work, and logs the user in.

Can FxA provide the same experience as Persona, where clicking the verify link completes the login process rather than waiting for the user to go back to the popup and click on something?

Comment 3

[Chris Karlof [:ckarlof]]

(In reply to Andy McKay [:andym] from comment #1)
> Not sure what the error=3005 is about.

That's an undocumented error from our client code to the relier signaling that we don't have enough information anymore to complete the flow. This could happen for a variety of reasons, but one of them is that you verified the email on a different machine than you started the create flow from. 

There are concerns about forgery attacks: http://tools.ietf.org/html/rfc6749#page-59

The standard defense against forgery attacks is to associate the "state" parameter you created with your client session, and then verify when OAuth completes that state provided in the callback matches the one previously associated with your session. If the verification completes in a 2nd browser, FxA "knows" that check will fail, so we have this error code that we used internally. However, it's not that friendly.

I recently decided that since the state might be used to convey other information (say in the preVerified flow), then we should arrange to make sure we get the state param back to you even if the user wants to continue in a 2nd browser. That's a WIP: https://github.com/mozilla/fxa-content-server/issues/1623

Comment 4

[Chris Karlof [:ckarlof]]

> Can FxA provide the same experience as Persona, where clicking the verify link completes the login process rather than waiting for the user to go back to the popup and click on something?

Yes, we could do that. Our UX guys initially decided on the flow we have. I believe they thought it would be too confusing for the flow to automatically complete and windows close magically, but hey, times change. John, Ryan?

Comment 5

[Chris Karlof [:ckarlof]]

FWIW, it may be simpler if we make the email link landing page a "dead end" if the user opens it on second device or browser. The alternative is a ping pong dance of getting another "state" param from the relier to make sure the request forgery protection is in place. Alternatively, we can can just redirect back and require the relier bounce the user back into the OAuth flow. 

Regardless, that's orthogonal to what happens on the original screen (autofinish the login flow or not).

Comment 6

[Chris Karlof [:ckarlof]]

Tracking issue in our front end: https://github.com/mozilla/fxa-content-server/issues/1723
PR for the fix: https://github.com/mozilla/fxa-content-server/pull/1725

Comment 7

[Chris Karlof [:ckarlof]]

> Can FxA provide the same experience as Persona, where clicking the verify link completes the login process rather than waiting for the user to go back to the popup and click on something?

We're going to do this, but I think we should support the user being able to continue back to Marketplace from the landing page from email verification or password reset link (as long as it's in the same browser). 

Consider the password reset process: I click on the password reset link, enter a new password, and then it just dead ends and I have to go back to the original tab and possibly re-enter the password? That seems strange to me.

Comment 9

[Chris Karlof [:ckarlof]]

https://github.com/mozilla/fxa-content-server/pull/1725 has been merged, and is available on our latest server. 

It entered the latest release train on 8/6/14

Comment 11

[Chris Karlof [:ckarlof]]

This fix has been released to prod and the stable integration server.