1050399 - [meta] Add Firefox Accounts to MDN's signon options

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: General, enhancement)

Description

[Justin Crawford [:hoosteeno] [:jcrawford]]

What problems would this solve?
===============================
Marketplace is getting close to implementing Firefox Accounts as their authentication system (https://bugzilla.mozilla.org/show_bug.cgi?id=1007956). Until MDN does, the potential of a unified account/profile system for developers may not be realized.

Who would use this?
===================
Developers who sign in to Mozilla's developer-facing systems.

What would users see?
=====================
Another authentication option in MDN's authentication dropdown. 

What would users do? What would happen as a result?
===================================================
* Developers would sign in using a Fx Account to any major developer-facing property at Mozilla and be delighted by the unified experience across sites. 
* The user population of each site would meld into a larger user population of all sites, enhancing the ecosystem and multiplying the reach of our numerous efforts on developers' behalf. 

Is there anything else we should know?
======================================

Comment 1

[Justin Crawford [:hoosteeno] [:jcrawford]]

Dev team can prioritize this. :groovecoder, LOE?

Comment 2

[Luke Crouch [:groovecoder]]

This is big. We should not just add FxA - we should migrate from Persona to FxA. It will realistically take us a whole quarter-long project, and we could only realistically start in Q3/Q4 time-frame, depending if/when we might also be moving from SCL3 data center to AWS.

Comment 3

[Justin Crawford [:hoosteeno] [:jcrawford]]

(In reply to Luke Crouch [:groovecoder] from comment #2)
> This is big. We should not just add FxA - we should migrate from Persona to
> FxA. It will realistically take us a whole quarter-long project, and we
> could only realistically start in Q3/Q4 time-frame, depending if/when we
> might also be moving from SCL3 data center to AWS.

Do we truly have to tightly couple "add option" with "migrate"? Yes, we need a migration. But coupling them makes the project bigger and harder to start -- is there value in coupling them, or could we simply have an "add FxA" project and a "sunset Persona" project?

Comment 4

[Luke Crouch [:groovecoder]]

302 :jezdez - technically we could have all 3 providers at once, but it would probably save us time overall to spend extra time now to migrate Persona to FxA, than to do drop Persona later.

:andym - did Marketplace consider supporting both providers for a time?

Comment 5

[Justin Crawford [:hoosteeno] [:jcrawford]]

FxA integration is now on the critical path for the Compat Data project.

Comment 6

[Jannis Leidel [:jezdez]]

Yeah, when we added GitHub the biggest impact on implementation complexity was the combination of Persona and GitHub as auth providers and shepherding Persona users to also accept GitHub as an option. The glue code that was necessary to match GitHub accounts to Persona accounts for example was non-trivial and developing the UX story took long.

I'm guessing that adding a third provider like FxA would require another pass over that matching code and design to be able to maximize the adoption rate of people that already have a Persona/GitHub hybrid account. We don't want to lose anyone, but also want to make the pipeline for new FxA users as easy as possible.

I think to thoroughly estimate this we need to have input from Stephanie about the UX.

Comment 7

[Andy McKay]

(In reply to Luke Crouch [:groovecoder] from comment #4)
> 302 :jezdez - technically we could have all 3 providers at once, but it
> would probably save us time overall to spend extra time now to migrate
> Persona to FxA, than to do drop Persona later.
> 
> :andym - did Marketplace consider supporting both providers for a time?

We did, but in the end decided to avoid it to avoid the technical work and UX complications. Instead we just went with a switch. Since marketplace had only one authentication method at the time, it would have been a bit more work to go from one to two, for a temporary period.

Comment 8

[Renoir Boulanger [:renoirb]]

Hi all, I subscribed to the issue to follow up the conversation and see how I can help.

Comment 9

[Renoir Boulanger [:renoirb]]

If I get the requirement right, the expected outcome is to use FxA as an authentication service and we are talking about some "way of knowing" which user to load within MDN. With this in place, we will also need a similar system within BrowserCompat.

If that’s the case, I’ve had to do this on WebPlatform Docs and I used FxA.

A solution path would be to make MDN answer to a POST request on a specific *Backend handler endpoint*, make an off the band (Python to some FxA service) request and return an HTTP payload. 

In my past implementation I created a JavaScript initializer that was handling communication through an hidden iframe, and making the calls to the *Backend handler endpoint*.

Here are some notes on my past work. 

* WebPlatform Docs: SSO and how we implemented it [1]
* SSO JavaScript initializer [2]
* FxA PR to support "SSO" behavior [3]

Other notes and details are linked in the PR [3].

HTH

[1] <https://docs.webplatform.org/wiki/WPD:Projects/SSO/How_we_implemented_it>
[2] <https://github.com/webplatform/www.webplatform.org/blob/master/src/files/assets/js/sso.js>
[3] <https://github.com/mozilla/fxa-content-server/pull/2637>

Comment 10

[Renoir Boulanger [:renoirb]]

I’d like to walk you through some code showing how it was done so you can see what I’m talking about.

The proof of concept I had working on WebPlatform was running on two separate wikis and a web app written in Python and Pyramid.

All in all, what the initializer [1] does is creating a hidden iframe and `iframe.postMessage()` to enquire about its local state and bootstrap the sync process.

If the accounts server is OK to reply (i.e. is OK with the origin[2]), it `.postMessage()` back postMessage with a one-time "code" for payload.

The initializer then makes a XMLHttpRequest POST to the backend handler.

All the backend has to do is to reply to requests on a specialized endpoint, do some communication to a profile server ("Source of truth").

The logic goes like this;

1. Get a bearer token in exchange of the code
2. Make a request to the "source of truth" (in my case it was a fork of FxA profile server)
3. Depending on the result from the profile server:
3.1 If response has an empty body, destroy local session
3.2 If the response has user data attached;
3.2.1 If no local user matches, create a user
3.2.2 Check if the data matches currently logged in user, sync if needed
4. Return an HTTP code (this needs polishing in my proof of concept implementation)

The backend tells the JavaScript initializer the outcome with an HTTP status code and an optional response body.

So how did we configure the initializer?

In MediaWiki;

```javascript
  var ssoOptions=ssoOptions||{logging:false, callbackUri:mw.config.get("wgArticlePath").replace('$1', 'Special:AccountsHandler/callback')};
  // Or any other way to attach a ...addEventListener to a specific DOM node.
  jQuery('body').on('click', '#pt-logout a',function(evt){evt.preventDefault();window.sso.signOut();});
```

In Hypothes.is [3];

```javascript
window.ssoOptions = {
  logging: ${str(request.webassets_env.debug).lower()},
  callbackUri: "${request.route_url('recover')}",
};
```

You can see the trigger event from this CoffeeScript within Hypothes.is [4] (see `$window.sso.init($window.ssoOptions);`).

As for the backend;

You can take a look at the PHP code I wrote [5][6] for MediaWiki, and what the guys at Hypothes.is did in Python [7].



[1] <https://github.com/webplatform/www.webplatform.org/blob/master/src/files/assets/js/sso.js>
[2] <https://github.com/webplatform/fxa-content-server/blob/webplatform-customizations/app/scripts/views/channel.js#L51>
[3] <https://github.com/webplatform/annotation-service/blob/master/notes_server/templates/base.pt#L7>
[4] <https://github.com/webplatform/annotation-service/blob/master/notes_server/static/scripts/auth.js#L14>
[5] <https://github.com/webplatform/mediawiki-fxa-sso/blob/master/includes/WebPlatformAuthHooks.php#L148>
[6] <https://github.com/webplatform/mediawiki-fxa-sso/blob/master/includes/specials/AccountsHandlerSpecialPage.php#L68>
[7] <https://github.com/webplatform/annotation-service/blob/master/notes_server/__init__.py#L75>

Comment 11

[John Whitlock [:jwhitlock]]

Current login on MDN is GitHub only. BrowserCompat is cancelled, and federated login across MDN properties is no longer an MDN need.

Comment 12

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.