User:Clouserw/AMO/Auth: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 19: Line 19:
* AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums).  Removing all that code will be very good.
* AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums).  Removing all that code will be very good.


=== Other Considerations ===
=== Q & A ===


* On certain administrative forms and when users try to delete their add-on we re-prompt for their password.  I don't think FxA supports this functionality.
* On certain administrative forms and when users try to delete their add-on we re-prompt for their password.  FxA doesn't support this functionality.  How will we deal with that?
** I think we'll just omit it for now.  Most administrative actions have moved to the CLI, and we have backups and logs for the other use cases.


* The [https://forums.mozilla.org/ AMO forums] still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system.  Three active proposals include:  letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).
* The [https://forums.mozilla.org/ AMO forums] still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system.  Three active proposals include:  letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).
Line 27: Line 28:
* What if someone uses an FxA account that doesn't match their AMO account?
* What if someone uses an FxA account that doesn't match their AMO account?
** Do we need to worry about this case?  If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.
** Do we need to worry about this case?  If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.
* Firefox Accounts supports the concept of pre-verified accounts meaning if I've already confirmed my email AMO could tell FxA that when I register and I wouldn't have to confirm again.
** This sounds like it may be more trouble than it's worth.  I'm going to sketch out the proposal without it and get feedback.

Revision as of 15:57, 13 May 2015

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Proposal to convert AMO to use Firefox Accounts

Converting AMO to use FxA would increase FxA numbers, simplify the AMO code, centralize our authentication at Mozilla, and reduce our vulnerability footprint by keeping all account info in one place. AMO has had 50,000 unique successful logins in April and 200,000 since the start of the year (stats as of the end of April).

This is a work in progress. Feedback encouraged.

Proposed Flow

This is based heavily on the Marketplace transition to Firefox Accounts.

Amo fxa.png

Engineering Considerations

  • AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums). Removing all that code will be very good.

Q & A

  • On certain administrative forms and when users try to delete their add-on we re-prompt for their password. FxA doesn't support this functionality. How will we deal with that?
    • I think we'll just omit it for now. Most administrative actions have moved to the CLI, and we have backups and logs for the other use cases.
  • The AMO forums still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system. Three active proposals include: letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).
  • What if someone uses an FxA account that doesn't match their AMO account?
    • Do we need to worry about this case? If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.
  • Firefox Accounts supports the concept of pre-verified accounts meaning if I've already confirmed my email AMO could tell FxA that when I register and I wouldn't have to confirm again.
    • This sounds like it may be more trouble than it's worth. I'm going to sketch out the proposal without it and get feedback.