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.

Calling navigator.mozId.watch prompts for password

RESOLVED FIXED

Status

Firefox OS
FxA
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: \, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

4 years ago
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
Flags: needinfo?(ferjmoreno)
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.
Flags: needinfo?(ferjmoreno)

Comment 3

4 years ago
Fernando is of course right. We'll replace the password challenge with a simple Yes/No permission for 2.2.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
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.
Resolution: WORKSFORME → FIXED
Even though emails from such a "leaked email address" bounce back...
s/emails from/emails to/

Comment 7

4 years ago
(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.
You need to log in before you can comment on or make changes to this bug.