FxA web channel attempts to use session token before it's ready
Categories
(Firefox :: Firefox Accounts, defect, P2)
Tracking
()
People
(Reporter: darktrojan, Unassigned)
References
Details
|
||
Comment 1•9 months ago
|
||
I wasn't really involved in the discussions about the webchannel changes for oauth, but I guess I'm mildly surprised we'd expect both :login and :oauth_login. Did you change the identity.fxaccounts.contextParam pref? I think it might need to be oauth_webchannel_v1 - and if so, that other boolean pref is a footgun. I'm asking in the #fxa channel to try and get to the bottom of this.
|
Reporter | |
Comment 2•9 months ago
|
||
Yes, I've been using oauth_webchannel_v1.
|
||
Comment 3•9 months ago
|
||
The severity field is not set for this bug.
:markh, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Comment 4•8 months ago
|
||
I wasn't really involved in the discussions about the webchannel changes for oauth, but I guess I'm mildly surprised we'd expect both :login and :oauth_login
Turns out I'm mildly surprised :) The expectation from Desktop's code is that we do see both :login and :oauth_login. We expect the former before the user/session is verified - this lets us set up the browser UI to reflect the "partial" connection - and does offer the session token, but they can't be used for many operations due to the account being unverified.
Finally, we expect :oauth_login when the user is fully complete. It is during/after this message that we are able to use the session token, able to get the sync keys from the content and so forth. If this happens without the login message, we don't have a session token.
I'm about to open another bug which may be a dupe of this, which I'll mark as "see also" - we can decide if it really is a dupe later.
|
|
||
Comment 5•5 months ago
|
||
This has all changed (and hopefully fixed!) as part of moving Firefox to oauth. Geoff, is this still a problem or an oddity for you?
|
|
Reporter | |
Comment 6•5 months ago
|
||
I'd like to say it works now (it probably does) but instead I'm stuck at an earlier part of the flow. My console reports
Prevented navigation to “urn:ietf:wg:oauth:2.0:oob:oauth-redirect-webchannel?code=...&state=...” due to an unknown protocol.
at the response to the authorization request and everything stops. I think this must be because of a server change rather than a client change as I've tried earlier builds back to July and they do the same thing. Any ideas?
|
|
||
Comment 7•5 months ago
|
||
hrm, I also guess this might be a server issue - we expect a redirection, but it's to a https:// url. It might be that the redirection depends on the oauth client id?
|
||
Comment 8•5 months ago
|
||
Hey Geoff, are you able to share the full URL or example URL you're testing with? I suspect you're hitting the condition of "oauth sync" when hitting authorization to get that back for the redirect, but you might be hitting the "web" condition in another place where we attempt to navigate using it.
|
|
Reporter | |
Comment 9•5 months ago
|
||
The page I'm looking at is
https://accounts.stage.mozaws.net/oauth/signin?
showReactApp=true&
deviceId=...&
flowBeginTime=...&
flowId=...&
context=oauth_webchannel_v1&
action=email&
service=sync&
client_id=8269bacd7bbc7f80&
response_type=code&
access_type=offline&
scope=https%3A%2F%2Fidentity.thunderbird.net%2Fapps%2Fsync%2Bprofile&
state=...&
code_challenge=...&
code_challenge_method=S256&
keys_jwk=...&
email=...
Which is the same as I see in Firefox except for the client_id and scope.
|
|
||
Comment 10•5 months ago
|
||
Thank you! I think I see the issue - FxA doesn't currently expect expect service=sync with that client ID, so we don't consider it sync, and my previous comment looks accurate. I'll get something filed on our side but might have a follow up question or two tomorrow.
|
|
Reporter | |
Comment 11•4 months ago
|
||
This appears to be all working now.
Description
•