bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Cannot "Sign in" to Hello using OAuth and a Firefox Account that is signed in to Sync

RESOLVED FIXED

Status

()

Firefox
Firefox Accounts
RESOLVED FIXED
3 years ago
8 months ago

People

(Reporter: nalexander, Assigned: stomlinson)

Tracking

40 Branch
x86_64
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
STR:

1) new profile, new Nightly (April 28).
2) create Firefox Account; verify account; verify that Sync is working.
3) click Loop icon; click Get Started.
4) click "Sign In or Sign Up", get bounced to (web) OAuth flow.
5) complete OAuth flow by clicking "Sign in".  Since the account is connected, there's no need to re-enter PW.
6) observe Loop panel popping out by no state changes: still Guest, and "Sign in or Sign Up" link is still present.

Browser console has the following:

Error: Encountered unsupported value type writing stack-scoped structured clone MozLoopAPI.jsm:268:39
unsafe CPOW usage TabState.jsm:96:0
Error: Encountered unsupported value type writing stack-scoped structured clone MozLoopAPI.jsm:268:39
OpenGL compositor Initialized Succesfully.
Version: 2.1 NVIDIA-10.2.7 310.41.25f01
Vendor: NVIDIA Corporation
Renderer: NVIDIA GeForce GT 750M OpenGL Engine
FBO Texture Target: TEXTURE_2D
A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Date: Tue Apr 28 2015 16:40:27 GMT-0700 (PDT)
Full Message: Error: OAuth flow failed. Keys were not returned
Full Stack: this.FxAccountsOAuthClient.prototype._registerChannel/listener@resource://gre/modules/FxAccountsOAuthClient.jsm:185:21
this.WebChannel.prototype.deliver@resource://gre/modules/WebChannel.jsm:306:9
WebChannelBroker<._listener@resource://gre/modules/WebChannel.jsm:86:13
 FxAccountsOAuthClient.jsm:185:0

This is very similar to Bug 1121640.
(Reporter)

Comment 1

3 years ago
(In reply to Nick Alexander :nalexander from comment #0)
> STR:
> 
> 1) new profile, new Nightly (April 28).
> 2) create Firefox Account; verify account; verify that Sync is working.

Sorry, I told a lie: I witness this behaviour consistently with a particular account.  Creating a new Firefox Account, I do not witness this behaviour.  Is it possible the existing account has unrelated Sync issues that are impacting this?  I certainly see Sync errors later in the console log, after all Hello interaction is done.
(Reporter)

Updated

3 years ago
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
(Reporter)

Comment 2

3 years ago
And even more details: if I cycle between accounts in the same profile, I can witness the issue only when there has not been an account connected already.

So {new profile, bad account} and {new profile, good account} both fail, suggesting this is *not* due to a particular account, but due to a problem with state.  {new profile, account -> alternate account -> original account} appears to always work.

Comment 3

3 years ago
ckarlof: does this behavior ring a bell?
Flags: needinfo?(ckarlof)
WebChannel had a fix that landed recently: Bug 1146724.

It's possible that this introduced a regression, but I'm not sure. Shane?
Flags: needinfo?(ckarlof) → needinfo?(stomlinson)
The particular error message here only triggers in very specific circumstances:

  if (this.parameters.keys && !data.keys) {
      err = new Error("OAuth flow failed. Keys were not returned");
  }

In other words, we asked for keys but the OAuth dance did not return them correctly.  The auth dance itself has completed properly.

From this:

> 5) complete OAuth flow by clicking "Sign in".  Since the account is connected, there's no need to re-enter PW.

I conclude this is a bug in the content-server.  If the relier requests keys, it should be prompting for the password regardless of the signed-in state of sync.  It will need the password to generate the keys.
To reproduce this: 
- Open Firefox Stable and sign in to sync. Try to open loop and make sure you see a sign-in prompt with no password requested: http://v14d.com/i/554044ed34a3d.jpg
- Close Firefox Stable
- Open Nightly, Try to signin to Loop. Get to this screen again http://v14d.com/i/554044ed34a3d.jpg, 
click signin. The icon will turn red.
(Reporter)

Comment 7

3 years ago
(In reply to Vlad Filippov from comment #6)
> To reproduce this: 
> - Open Firefox Stable and sign in to sync. Try to open loop and make sure
> you see a sign-in prompt with no password requested:
> http://v14d.com/i/554044ed34a3d.jpg
> - Close Firefox Stable
> - Open Nightly, Try to signin to Loop. Get to this screen again
> http://v14d.com/i/554044ed34a3d.jpg, 
> click signin. The icon will turn red.

I can confirm that my icon turns red.  I also think that I see an immediate "Sync failure" dark error bar, which goes away when I force a sync.  Perhaps there's a legitimate race to create a good token server token or otherwise authenticate?
(In reply to Ryan Kelly [:rfkelly] from comment #5)
> I conclude this is a bug in the content-server.  If the relier requests
> keys, it should be prompting for the password regardless of the signed-in
> state of sync.  It will need the password to generate the keys.

Makes sense. This probably affects Aurora, too, I imagine. 

Re-prompting for the password is a decent short term fix, but if the user requests a
Component: Client → FxAccounts
Product: Loop → Core
Flags: needinfo?(stomlinson)
(In reply to Ryan Kelly [:rfkelly] from comment #5)
> I conclude this is a bug in the content-server.  If the relier requests
> keys, it should be prompting for the password regardless of the signed-in
> state of sync.  It will need the password to generate the keys.

Makes sense. This probably affects Aurora, too, I imagine. 

Re-prompting for the password is a decent short term fix, but the "no password for subsequent logins" property is then lost. Something to ponder.
rfk, could you add a content server bug link here when you get a chance?
Flags: needinfo?(rfkelly)
Adding as blocking the Hello context in conversations/encryption work.
Blocks: 1115340, 1153806
(Assignee)

Comment 12

3 years ago
Here is a fix on the content server to force the user to enter their password if the OAuth relier specifies 'keys=true':

diff --git a/app/scripts/views/sign_in.js b/app/scripts/views/sign_in.js
index f06842f..e263bf2 100644
--- a/app/scripts/views/sign_in.js
+++ b/app/scripts/views/sign_in.js
@@ -273,6 +273,10 @@ function (Cocktail, p, BaseView, FormView, SignInTemplate, Session,
         return true;
       }
 
+      if (this.relier.wantsKeys()) {
+        return true;
+      }
+
       // We need to ask the user again for their password unless the credentials came from Sync.
       // Otherwise they aren't able to "fully" log out. Only Sync has a clear path to disconnect/log out
       // your account that invalidates your sessionToken.
We'll be doing a v0.36.1 release to address this issue. 

Content server bug: https://github.com/mozilla/fxa-content-server/issues/2356
(Clearing rfk needinfo because I linked the bug)
Flags: needinfo?(rfkelly)
(Assignee)

Updated

3 years ago
Assignee: nobody → stomlinson
(Assignee)

Updated

3 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 14

3 years ago
A PR has been opened against the content server: https://github.com/mozilla/fxa-content-server/pull/2357
Fixed in content server v0.36.1, the fix will be applied when train-36 gets deployed.
To clarify, this issue only affects Nightly, and *not* Aurora, Beta or Stable.

Thanks so much Shane for quickly providing a pull request for this!
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Version: unspecified → 40 Branch
I love the ones where you go to bed with an outstanding ni?, wake up the next morning and it's already fixed.  Thanks team!  :-)
FxA train-36 was deployed (https://bugzilla.mozilla.org/show_bug.cgi?id=1161415#c1). I can no longer reproduce the issue.

Updated

8 months ago
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.