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

Status: RESOLVED FIXED

(Firefox :: Firefox Accounts, defect)

Description

[Nick Alexander :nalexander [he/him]]

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.

Comment 1

[Nick Alexander :nalexander [he/him]]

(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.

Comment 2

[Nick Alexander :nalexander [he/him]]

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

[Adam Roach [:abr]]

ckarlof: does this behavior ring a bell?

Comment 4

[Chris Karlof [:ckarlof]]

WebChannel had a fix that landed recently: Bug 1146724.

It's possible that this introduced a regression, but I'm not sure. Shane?

Comment 5

[Ryan Kelly [:rfkelly]]

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.

Comment 6

[Vlad Filippov (:vladikoff)]

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.

Comment 7

[Nick Alexander :nalexander [he/him]]

(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?

Comment 8

[Chris Karlof [:ckarlof]]

(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

Comment 9

[Chris Karlof [:ckarlof]]

(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.

Comment 10

[Chris Karlof [:ckarlof]]

rfk, could you add a content server bug link here when you get a chance?

Comment 11

[Mark Banner (:standard8)]

Adding as blocking the Hello context in conversations/encryption work.

Comment 12

[Shane Tomlinson [:stomlinson]]

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.

Comment 13

[Vlad Filippov (:vladikoff)]

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)

Comment 14

[Shane Tomlinson [:stomlinson]]

A PR has been opened against the content server: https://github.com/mozilla/fxa-content-server/pull/2357

Comment 15

[Vlad Filippov (:vladikoff)]

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!

Comment 16

[Ryan Kelly [:rfkelly]]

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!  :-)

Comment 17

[Chris Karlof [:ckarlof]]

FxA train-36 was deployed (https://bugzilla.mozilla.org/show_bug.cgi?id=1161415#c1). I can no longer reproduce the issue.