The desired behaviour:
* If we have no account now, and had no account or the same account in
the past -- no message, allow.
* If we have no account now, but had a different account in the past -- prompt.
* If we have an account, and this is the same account -- no message, allow.
* If we have an account, and this is not the same account -- toast and
never allow.
This ticket does the following things:
* register early. If the first page that Gecko loads is
about:accounts, the channel needs to be in place. If we delay this,
we can and do miss content server messages.
* listen to the following messages:
CAN_LINK_ACCOUNT: 'fxaccounts:can_link_account'
CHANGE_PASSWORD: 'fxaccounts:change_password'
DELETE_ACCOUNT: 'fxaccounts:delete_account'
LOADED: 'fxaccounts:loaded'
LOGIN: 'fxaccounts:login'
The list of messages is from
2a78a14daf/app/scripts/models/auth_brokers/fx-desktop-v2.js (L24)
via
2a78a14daf/app/scripts/models/auth_brokers/fx-fennec-v1.js
This patch implements only LOADED, LOGIN, and CHANGE_PASSWORD. The
messages have the following behaviour:
A LOADED message is ferried to the individual XUL <browser> element it
originated from. In general, WebChannel is a global listener: it does
not matter where a message originates. We want to have fine-grained
control over when an embedding <iframe> is displayed (as opposed to
loaded, in the Gecko sense of loaded). The fxa-content-server
participates in this exchange via the LOADED message; we complete the
loop by specially handling LOADED.
A LOGIN or CHANGE_PASSWORD message either creates a new Android
Account in the Engaged state, or moves an existing Android Account to
the Engaged state. An Android sync is not yet requested -- we'll
arrange that from the Java side.
This always loads about:accounts with an 'action' query parameter.
This indirection allows Gecko to manage the fxa-content-server pref
independently of Java.
This commit does a few things. First, it fixes a typo
(s/ForResponse/ForResult/). It's not clear how this /ever/ worked,
but it did.
Second, it adds an UpdateAccountFromJSON sibling to
CreateAccountFromJSON. It would have been reasonable to have the
create message do double-duty and update an existing account (we have
the latitude to change the meaning since this API is not yet public)
but I generally prefer each consumer to perform the conditional state
check and to act appropriately.
Third, it generalizes the existing Accounts:Exist message to provide
some details (including email and UID) of any existing Firefox
Account. The Accounts.exist() API /is/ public, so I introduce a new
(not yet public) API for this richer information.
There are enough Accounts: messages to separate them from BrowserApp,
and the list is only growing.
This has also the small advantage of removing some non-native event
listeners.
This patch stops referring to package/class objects to identify
Android components directly and instead launches through action intent
filters. The intent filters are scoped to the package, but not marked
as private or as requiring a permission. A malicious package could
inject itself into an account flow, but I don't think there's much
advantage: the only time a secret is passed between activities is when
the native sign up (CreateAccount) and sign in (SignIn) activities
link between themselves, and in this instance I didn't route through
the action intent filters. (This is entirely native -- there's no web
analog -- so I didn't use the indirection.)
