CC Ed as he designed the most recent improvements to the autoconfig stuff.
(In reply to Ryan Kelly [:rfkelly] from comment #6)
rfkelly, is there a bug to expose a FxA jsm API to get identity.fxaccounts.autoconfig.uri || identity.fxaccounts.remote.root?
There is not. We should definitely add such an API. Adding this as a blocker to Bug 1565960, which is our nascent metabug for "clean up FxAccounts.jsm API surface for public consumpion".
Should that just be added as part of this bug and get reviewed by.. stomlinson ?
Doing it as part of this bug sounds great, and :markh is probably the best person for detailed guidance and review. Mark, does that sound right?
I'm not sure what this API should look like though - for clarity (and to expand on what Shane said):
identity.fxaccounts.autoconfig.uri is not set by default. If it is set, the configuration values that end-point returns could be on a completely different server - for example, while it probably doesn't make much sense, there's no reason a custom autoconfig URL couldn't return our FxA servers. Further, this pref only makes sense to look at if there's no user signed in.
identity.fxaccounts.remote.root has a default value pointing at our FxA servers - but if no user is signed in, it will be overwritten if identity.fxaccounts.autoconfig.uri is set. IOW, this only makes sense to look at when a user is signed in.
It seems you probably only care about this when a user is signed in, right? If so, it probably makes sense to just add a
promiseRootURI() method to FxAccountsConfig.jsm, which you'd access via
However, this begs the question of exactly how this would be used - for example, I notice that AS links to things like /legal/terms and /legal/privacy - which about:preferences#sync also links to - and sadly, these are done in a different way via yet different preferences sob - so really, I think we should consider adding
promiseLegalPrivacyURI() methods instead and ensure they are used consistently. I recall some earlier discussion deciding that these URLs should always point to our notices, even if a custom server is used, so adding these methods to FxAccountsConfig.jsm would ensure the same policy is used everywhere.
In what other cases would the root URI be necessary? ie, I'm trying to work out if exposing the 'root' URI is a future footgun and we should just add multiple methods which target a specific end-point to discourage consumers from building their own URLs at all? Regardless, adding new entries is very easy (but a complication is that they all return promises, whereas prefs are sync)