Closed
Bug 1072267
Opened 10 years ago
Closed 10 years ago
Cannot start marketplace from Firefox Accounts verification confirmation page
Categories
(Cloud Services :: Server: Firefox Accounts, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: vcarciu, Assigned: ckarlof)
References
Details
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•10 years ago
|
||
Not sure what the error=3005 is about.
Assignee: nobody → ashort
Priority: -- → P3
Comment 2•10 years ago
|
||
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?
Flags: needinfo?(ckarlof)
Assignee | ||
Comment 3•10 years ago
|
||
(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
Flags: needinfo?(ckarlof)
Assignee | ||
Comment 4•10 years ago
|
||
> 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?
Flags: needinfo?(jgruen)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(rfeeley)
Assignee | ||
Comment 5•10 years ago
|
||
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).
Assignee | ||
Comment 6•10 years ago
|
||
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
Assignee | ||
Comment 7•10 years ago
|
||
> 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.
Updated•10 years ago
|
Assignee: ashort → ckarlof
Component: Integration → Server: Firefox Accounts
Product: Marketplace → Mozilla Services
Target Milestone: 2014-09-30 → ---
Version: Avenir → other
Assignee | ||
Comment 9•10 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(rfeeley)
Flags: needinfo?(jgruen)
Assignee | ||
Comment 11•10 years ago
|
||
This fix has been released to prod and the stable integration server.
You need to log in
before you can comment on or make changes to this bug.
Description
•