Fx Desktop API glue needed.

[shane-tomlinson]

No description provided.

[shane-tomlinson]

@zaach pointed me here:

https://github.com/mozilla/fxa-content-server/blob/master/static/javascripts/flow.js#L102-L114
and
https://github.com/mozilla/fxa-content-server/blob/master/static/javascripts/common.js#L310

In fact, I have already done an experiment with this code here:
https://github.com/shane-tomlinson/fxa-content-server/blob/complete-flow/app/scripts/lib/channels/fx-desktop.js

I will re-package that code into something a bit more sane.

[shane-tomlinson]

@zaach - Is there a list of possible commands that come from the browser and a list of commands the browser is expecting anywhere?

[zaach]

Here is one!

List of commands the browser expects and its responses (expects -> response):

• login -> login
• session_status -> session_status
• sign_out -> sign_out

Besides those ack style responses, the browser can also respond with error, e.g. here.

[ckarlof]

warning: the Firefox Desktop Glue API and requirements should not be considered anywhere close to finalized, but @zaach list of commands is a good start.

Edit: should -> should not

[shane-tomlinson]

@zaach - so that I understand the flow better, and so that there is a record of how the pieces fit together, can you give a synopsis of how it fits together or refute what I am writing?

My understanding:

• User tries to sign in to a service on the browser that requires FxA. Browser opens an iframe to <fxa_content_server>/signin or <fxa_content_server>/signup depending on what the user is trying to do.
• When the user signs in, hosted content sends a login command and expects a login response from the browser.
• When the user signs up, hosted content sends a login command and expects a login response when the "confirm your email" screen is displayed (or after email verification?)

Questions:

• When are session_status and sign_out sent?
• If a user signs in successfully in hosted content but the login handler sends back an error, what then?
• Does the browser close the iframe when it knows sign in is complete?

Do I have this all backwards? At first, I assumed the browser sent a login command and the hosted content went to the /signin screen, but after looking over your links, that assumption seems to be backwards.

[shane-tomlinson]

From @zaach's comment in #162:

How it currently works:

• Chrome code loads hosted FxA in an iframe
• hosted FxA sends messages to chrome using custom FirefoxAccountsCommand.
• chrome code sends messages to hosted FxA using postMessage

Ideally we could abstract this a bit and make it a bidirectional channel, rather than disparate events.

[shane-tomlinson]

More from @zaach's comments in #162:

The vital pieces of information that Sync needs after sign up/in are the email, sessionToken, keyFetchToken, and unwrapBKey. The client should take care of fetching these values.

E.g.: https://github.com/mozilla/fxa-content-server/blob/master/static/javascripts/flow.js#L98-L108

[zaach]

When are session_status and sign_out sent?

session_status is sent from hosted content to the browser to determine what screen it should show when about:accounts is loaded. If a session exists, currently it should show a sign_out button, otherwise a sign up screen. When the sign out button is clicked, the hosted code sends sign_out to the browser.

If a user signs in successfully in hosted content but the login handler sends back an error, what then?

Good question. That's not really handled currently. We'll have to make sure the flows account for this error case.

Does the browser close the iframe when it knows sign in is complete?

Not at this point; currently there should be a transition to a "setup complete" page. I'm not sure what the new flows suggest for this, but the browser doesn't currently close the frame.

[ckarlof]

I'm skeptical whether session_status and sign_out will make it into production, FWIW.

[zaach]

Do I have this all backwards? At first, I assumed the browser sent a login command and the hosted content went to the /signin screen, but after looking over your links, that assumption seems to be backwards.

What you wrote looks right. The hosted page sends the login event immediately after the user completes signIn (not waiting for email verification on sign ups).

[shane-tomlinson]

@zaach merged #191, closing.