959338 - Verifying an email causes the account to sign out from the device.

Status: RESOLVED DUPLICATE of bug 943521

(Firefox OS Graveyard :: FxA, defect)

Description

[Fernando Jiménez Moreno [:ferjm]]

It seems that we are triggering a logout from the device when a email verification is done.

I am using the legacy server (https://api-accounts-legacy.dev.lcip.org/v1) for these tests:

Gecko  I  1389643719342 FirefoxAccounts  DEBUG     (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/raw_password/account/create - Method: POST - Payload: {"email":"667861406d61696c696e61746f722e636f6d","password":"12345678"}
Gecko  I  1389643721654 FirefoxAccounts  DEBUG     (Response) Code: 200 - Status text: OK - Response text: {"uid":"05a757bfa73246659158475c43975a77"}
Gecko  I  1389643721671 FirefoxAccounts  DEBUG     (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/raw_password/session/create - Method: POST - Payload: {"email":"667861406d61696c696e61746f722e636f6d","password":"12345678"}
Gecko  I  1389643724213 FirefoxAccounts  DEBUG     (Response) Code: 200 - Status text: OK - Response text: {"uid":"05a757bfa73246659158475c43975a77","verified":false,"sessionToken":"b4db08308a68e0b9eb63ae95abe0ead3b1c9a4c43ab28d99601437f58532158f"}

Gecko  I  1389643734069 FirefoxAccounts  DEBUG     (HAWK request) - URI: https://api-accounts-legacy.dev.lcip.org/v1/recovery_email/status - Method: GET - Payload: undefined
Gecko  I  1389643734335 FirefoxAccounts  DEBUG     (Response) Code: 200 - Status text: OK - Response text: {"email":"[e-mail]","verified":true}
Gecko  I  1389643734341 FirefoxAccounts  DEBUG     checkEmailStatus -> {"email":"[e-mail]","verified":true}
Gecko  I  1389643734640 FirefoxAccounts  DEBUG     fetchAndUnwrapKeys: token: undefined
Gecko  I  1389643734641 FirefoxAccounts  DEBUG     Polling aborted; Another user signing in
Gecko  I  1389643734642 FirefoxAccounts  DEBUG     generationCount: 5
Gecko  I  1389643734669 FirefoxAccounts  DEBUG     Notifying observers of fxaccounts:onlogout 


It seems that we are not getting at [1] the 'keyFetchToken' value expected for [2] and so we are signing out.

[1] http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#333
[2] http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#162

Comment 1

[Sam Penrose]

I was not able to reproduce with Friday's m-c and either Gaia main from today or an older branch. I upgraded m-c and now Gaia main won't get through FTU for me. The older branch, fxa_proposal_complete, still allows me to sign up and verify with no problem. As m-c and gaia main are updated I will try to get past FTU.

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Sam Penrose from comment #1)
> I was not able to reproduce with Friday's m-c and either Gaia main from
> today or an older branch. I upgraded m-c and now Gaia main won't get through
> FTU for me. The older branch, fxa_proposal_complete, still allows me to sign
> up and verify with no problem. As m-c and gaia main are updated I will try
> to get past FTU.

The FTU part is not landed yet, that's Bug 897600, so you'll need to use the Test-FxA-Client app (already in Gaia master, you'll need an engineering build to get the test apps).

However, I should have given more clear STR. We are able to login and verify the account, but verifying the account causes a logout event that is not appreciated until the next reboot because of Bug 959535 (we are consuming the cached account even if it has already logged out, I'll fix this in that bug). So the STR would be:

- Open Test-FxA-Client app.
- Launch FxA flow.
- Complete FxA flow sign up process.
- Go to your inbox and verify the account.
- Check that the account is still logged.
- Reboot the device.
- Check that the account is no logged anymore.

I've recorded a video of the issue: https://vimeo.com/84124597

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

Note that I've modified the debug message at [1] to include the topic (fxaccounts:logout in this case) of the notification and show the issue in a better way.

[1] https://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm#350

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

Sam, are you able to reproduce following the STR from comment 2?

Comment 5

[Sam Penrose]

ferjm I don't have a flashable device right now, so I can't attempt the STR. One is on order. I would suggest that we assume your diagnosis is correct and move forward without reproducing on other hardware. If you want me to make reproducing a priority, let me know and I will find someone to do it or borrow a device.

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Sam Penrose from comment #5)
> ferjm I don't have a flashable device right now, so I can't attempt the STR.
> One is on order. I would suggest that we assume your diagnosis is correct
> and move forward without reproducing on other hardware. If you want me to
> make reproducing a priority, let me know and I will find someone to do it or
> borrow a device.

You can test it with b2g-desktop as shown in the video, it is not device dependent. Anyway, it's ok, I just wanted to confirm that it wasn't just me seeing this issue :).

Chris, any idea of why aren't we getting the (expected?)'keyFetchToken' value when doing the raw_password requests? I can't find any docs for the raw password API so I don't know if this is a server or a client issue. If it is a client issue, I am also not sure if it is worth fixing it to work with the legacy server since bug 943521 is supposed to change the client soon to work with the new server.

Comment 7

[Chris Karlof [:ckarlof]]

Hi ferjm,

1) Since we made the /raw_password API obsolete, we removed the documentation. Here is an old ref:
https://github.com/mozilla/fxa-auth-server/blob/d9e74ff2a0a75be73a308f51f4e9e50bb27cb279/docs/api.md#post-v1raw_passwordsessioncreate

As far as I know, this API never returned the keyFetchToken. This is being replaced with /account/login or /account/login?keys=true depending on whether you need the sync keys are not (https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#post-v1accountlogin). I expect FxOS will not need the sync keys (for now), so it should use the former, which will not return the keyFetchToken either.

2) So what happened?

I'm not sure. However, I suspect any errors in key fetching prior to Bug 951118 would fail silently (see http://hg.mozilla.org/mozilla-central/diff/f3d509e75433/services/fxaccounts/FxAccounts.jsm).

However, the logic in getKeys is weird (http://mxr.mozilla.org/mozilla-central/source/services/fxaccounts/FxAccounts.jsm).

137   getKeys: function() {
138     return this.getUserAccountData().then((data) => {
139       if (!data) {
140         throw new Error("Can't get keys; User is not signed in");
141       }
142       if (data.kA && data.kB) {
143         return data;
144       }
145       if (!this.whenKeysReadyPromise) {
146         this.whenKeysReadyPromise = Promise.defer();
147         return this.fetchAndUnwrapKeys(data.keyFetchToken)
148           .then((data) => {
149             if (this.whenKeysReadyPromise) {
150               this.whenKeysReadyPromise.resolve(data);
151             }
152           });
153       }
154       return this.whenKeysReadyPromise.promise;
155       });
156    },

This function can return two different promises, depending on whether this.whenKeysReadyPromise exists or not. The lack of the return on line 147 caused any error in fetchAndUnwrapKeys to fail silently because the error wasn't handled. The addition of the return on line 147 bubbles up the error, but now the data and errors are handled by two different promises (???). This seems like a bug to me, or confusing design. Maybe I'm missing something.

Perhaps instead we should do 

145       if (!this.whenKeysReadyPromise) {
146         this.whenKeysReadyPromise = this.fetchAndUnwrapKeys(data.keyFetchToken);
147       }
148       return this.whenKeysReadyPromise;

Regardless, I'm not sure how this ever worked on FxOS with /raw_password, because as far as I know that API never returned a keyFetchToken. One way that could have worked is because of Bug 959825 (this should be added, where keys are not fetched during a login with an already verified email. I.e., keys are currently only fetched after login when the email is unverified and the browser detects it becomes verified. This is the common case after a create account flow.

3) What do we do?

I see two options:

1) Move ASAP to /account/login?keys=true on FxOS. This will give you a keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't need them, but I suspect we'll need them sometime in the future.

2) Don't treat the lack of a keyFetchToken as an error case which logs the user out. Sync on Desktop always requires a keyFetchToken during login, so this error would have to be handled elsewhere. Granted, it's not handled that well as it is, so I'm not sure this option would make it any worse.

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

Thanks Chris!

(In reply to Chris Karlof [:ckarlof] from comment #7)
> 
> 1) Move ASAP to /account/login?keys=true on FxOS. This will give you a
> keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't
> need them, but I suspect we'll need them sometime in the future.

I'd go with this solution. If I am not wrong bug 943521 is going to do this.

Comment 9

[Chris Karlof [:ckarlof]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #8)
> Thanks Chris!
> 
> (In reply to Chris Karlof [:ckarlof] from comment #7)
> > 
> > 1) Move ASAP to /account/login?keys=true on FxOS. This will give you a
> > keyFetchToken. It's weird that FxOS fetches the sync keys when it doesn't
> > need them, but I suspect we'll need them sometime in the future.
> 
> I'd go with this solution. If I am not wrong bug 943521 is going to do this.

You are correct.

Comment 10

[Fernando Jiménez Moreno [:ferjm]]

Closing this as a dup of bug 943521. Feel free to reopen if you disagree.