1098036 - Calling navigator.mozId.watch prompts for password

Status: RESOLVED FIXED

(Firefox OS Graveyard :: FxA, defect)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

So I just reloaded my app, which calls navigator.mozId.watch on launch, which suddenly throws up a login prompt (specifically asking for password, not email address).  This is unexpected and different behavior from persona.  I believe I was still logged in from last launch of the application.

Why is watch prompting for login?  Shouldn't navigator.mozId.request do that?

Comment 1

[Sam Penrose]

This is probably a bug; if so the fix is simple, though not simple to get into 2.0.

mozId.watch() bubbles down to FxAccountsManager.getAssertion() at [1], passing in {silent: true}. If the user is not logged in, it returns null, and the onlogout() callback ends up being fired. If the user is logged in, onlogin() is supposed to fire with an assertion. However, when we added permissions testing for privileged apps to this function, we fire the password challenge (l.563) well before testing for silent (l.579). Thus, watch() and not just request() can trigger the dialog. There is no workaround except not calling watch() until you are prepared to be interrupted by the dialog, which is not good.

I am inclined to move the test for silent earlier to prevent watch() from calling it. I do not know if it is possible to uplift to 2.0, but this issue does not feel important enough to me. We could try for 2.1. Fernando, what do you think?

[1] https://github.com/mozilla/gecko-dev/blob/master/services/fxaccounts/FxAccountsManager.jsm#L508

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

We are only prompting for the password the first time a new privileged app is requesting access to an existing FxA information. This is by design as decided on bug 1028398. We needed to make sure that the user was aware about the new app asking for her FxA information. We reused the current refresh authentication screen because we couldn´t add any new string on 2.0 at that point, but it probably makes sense to change this now with a better explanation for 2.2 (maybe it´s already too late for 2.1). We don't really need the password (unless the RP explicitly asks for it). All that we need is a way to ask the user to give permission to share her FxA information with the app calling navigator.mozId. This would require a new screen in the FxA flow.

Comment 3

[Sam Penrose]

Fernando is of course right. We'll replace the password challenge with a simple Yes/No permission for 2.2.

Comment 4

[(not reading bugmail) Nick Desaulniers [:\n]]

So to make sure I understand this correctly:

In order not to leak the user's email address to any privileged app using FxA, the expected behavior when invoking navigator.mozId.watch for the very first time in an app is to prompt the user for their password.

Does that sound right?  We should update the docs if it is.

Comment 5

[(not reading bugmail) Nick Desaulniers [:\n]]

Even though emails from such a "leaked email address" bounce back...

Comment 6

[(not reading bugmail) Nick Desaulniers [:\n]]

s/emails from/emails to/

Comment 7

[Sam Penrose]

(In reply to Nick Desaulniers [:\n] from comment #4)
> So to make sure I understand this correctly:
> 
> In order not to leak the user's email address to any privileged app using
> FxA, the expected behavior when invoking navigator.mozId.watch for the very
> first time in an app is to prompt the user for their password.
> 
> Does that sound right?  We should update the docs if it is.

Yes. Docs updated.