Integrate with recroom

[ozten]

We should make it easy to put your packaged app on recroom.

recroom distribute-beta

https://github.com/mozilla/recroom

For a very basic 1.0, recroom could just send the user to the homepage, which will redirect to their dashboard if they are already authenticated.

For a better experience, we can build hawk or OAuth authentication into recroom's CLI and BetaFox's REST API. recroom would make sure the user was authenticated, then do the upload for them, then launch their app install page.

via @rorito @tofumatt

[tofumatt]

Cool! Thumbs up from me!

• tofumatt

[ozten]

Work in Progress in https://github.com/mozilla/betafox/blob/recroom-cli/docs/CLI_AUTH.md

/CC @warner

[wrr]

I'm here from the Persona mailing list, and I'm not familiar with BetaFox, so please ignore my comment if it doesn't make much sense from the BetaFox architecture perspective.

One tricky thing is to consider what happens when a malicious user obtains an auth token via /cli/start-session, and then points an honest user to the /cli/auth/badec0ffee123456789f site.

On a /cli/auth/badec0ffee123456789f site the user should be presented with a very carefully worded message that makes it clear that the next action (a click of a button for instance) will authorize a client, and that the user should not proceed if the authorization was not initiated by her. The confirmation step seems to be necessary. For example, if the user already has an active session with the site, or the Persona automatic login mechanism logs the user, the authorization token should not be granted automatically.

[ozten]

@wrr Thanks! It's a good point, will do.

[ozten]

I've updated the proposal with Warner's feedback, as well as Jan's. https://github.com/mozilla/betafox/blob/recroom-cli/docs/CLI_AUTH.md

[warner]

you might consider having the user cut-and-paste some output of the CLI tool into the browser window where they're doing the authorization, to bind the two things together

[ozten]

I don't like the UX tradeoffs there.

[warner]

Yep. A less-annoying approach could be to have the CLI tool display something, and the browser window displays the same thing, and a conscientious user can compare the two before approving the web flow. (And an impatient user can ignore it).

Maybe use a "correct-horse-battery-staple" -style randomly-generated phrase, which would be easier to compare than a hex string. It doesn't need to be very long: in this case, the attacker (redirecting your browser to a page that approves their own request) doesn't get any information about the real request, so a 10-bit code would reduce their chances to one-in-a-thousand.