Closed Bug 1463316 Opened 7 years ago Closed 4 years ago

Include webextension storage endpoints in fxa-client-configuration

Categories

(Cloud Services :: Server: Firefox Accounts, defect)

Product:
Cloud Services
Component:
Server: Firefox Accounts
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: markh, Unassigned)

References

Details

Via bug 1462615, if a user configures Firefox to use the non-prod FxA end-points, most of Sync and FxA are auto-configured correctly although the webextension-storage endpoints are not. If fxa-client-configuration returned these end-points, Firefox should then be able to be made to work as expected. It seems that for accounts.stage.mozaws.net, the relevant endpoint is https://webextensions-settings.stage.mozaws.net/v1 - however, I'm not sure what the matching endpoint for dev is.
Blocks: 1462615
It's also not clear what the right URL would be for self-hosted environments, or whether we should default to disabling it somehow in order to avoid errors.
Ethan, can you confirm an appropriate kinto-we endpoint to use for stage, and any other well-known kinto endpoints that might be suitable for other environments?
Flags: needinfo?(eglassercamp)
Yes, the URL you gave is the correct one for kintowe stage. I don't think we have a dev stack (it isn't listed in https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=65342460). I'm concerned that kintowe stage doesn't point to FxA stage. I've asked :philipcristiano to check whether that's true or not.
Flags: needinfo?(eglassercamp) → needinfo?(pcristiano)
AFAICT, kintowe -stage has been using "fxa-oauth.oauth_uri = https://oauth.accounts.firefox.com/v1" since the beginning of the project. I can file a PR to fix that if some one let me know what the correct URL is for kintowe -stage.
Flags: needinfo?(pcristiano)
So...it depends on what you want to use kintowe-stage for. Some other reliers (e.g. AMO) like to have their stage environment talking to the production FxA environment so that it reflects production as closely as possible. In other cases, it's more useful to have Stage talking to Stage so they can all be QAed together. I feel like having Stage talk to Stage will be more useful in this case, just as the stage sync servers talk to FxA stage. But ultimately that's up to you :glasserc and co.
I guess we have to have some kintowe environment that works to use with FxA stage, or else we'll definitely have bugs like bug 1462615 forever. It may as well be kintowe-stage now that the deployment is pretty stable. :rfkelly, could you confirm that the corresponding stage URI is https://oauth.stage.mozaws.net/v1 ? :wezhou, once :rfkelly gives the go ahead, could you file the PR you mentioned?
Flags: needinfo?(wezhou)
Flags: needinfo?(rfkelly)
> :rfkelly, could you confirm that the corresponding stage URI is https://oauth.stage.mozaws.net/v1 Yes, that's correct.
Flags: needinfo?(rfkelly)
kintowe-stage is now configured to talk to fxa-stage. Please test.
Shane, I'd like to get your take on this. The current contents of our fxa-client-configuration files are: ``` $> curl --silent https://accounts.firefox.com/.well-known/fxa-client-configuration | json_pp { "auth_server_base_url" : "https://api.accounts.firefox.com", "oauth_server_base_url" : "https://oauth.accounts.firefox.com", "profile_server_base_url" : "https://profile.accounts.firefox.com", "sync_tokenserver_base_url" : "https://token.services.mozilla.com" } $> $> $> curl --silent https://accounts.stage.mozaws.net/.well-known/fxa-client-configuration | json_pp { "auth_server_base_url" : "https://api-accounts.stage.mozaws.net", "oauth_server_base_url" : "https://oauth.stage.mozaws.net", "profile_server_base_url" : "https://profile.stage.mozaws.net", "sync_tokenserver_base_url" : "https://token.stage.mozaws.net" } $> ``` The proposal here is to add another key, perhaps "sync_webext_settings_base_url", so they they look like: ``` $> curl --silent https://accounts.firefox.com/.well-known/fxa-client-configuration | json_pp { "auth_server_base_url" : "https://api.accounts.firefox.com", "oauth_server_base_url" : "https://oauth.accounts.firefox.com", "profile_server_base_url" : "https://profile.accounts.firefox.com", "sync_tokenserver_base_url" : "https://token.services.mozilla.com", "sync_webext_settings_base_url" : "https://webextensions.settings.services.mozilla.com", } $> $> $> curl --silent https://accounts.stage.mozaws.net/.well-known/fxa-client-configuration | json_pp { "auth_server_base_url" : "https://api-accounts.stage.mozaws.net", "oauth_server_base_url" : "https://oauth.stage.mozaws.net", "profile_server_base_url" : "https://profile.stage.mozaws.net", "sync_tokenserver_base_url" : "https://token.stage.mozaws.net", "sync_webext_settings_base_url" : "https://webextensions-settings.stage.mozaws.net" } $> ``` On one hand, I'm concerned about proliferating more values into that document that FxA shouldn't really need to know about; on the other hand, it's a rightful sibling to the sync URL that's already in there, and including it will help SoftVision avoid confusing setups like Bug 1462615. Thoughts?
Flags: needinfo?(stomlinson)
Being more of a pragmatist than dogmatist, I only cringe slightly, though it seems we are conflating two discovery systems: 1) Firefox services discovery in general 2) FxA metadata We had *a lot* of discovery proposals 4 years ago [1][2][3][4], including talk about providing an OpenID Connect compatible metadata endpoint. We settled on the current format for reasons I no longer remember. Are we going to keep adding new entries because it's the only discovery system Firefox currently has? If so, does it make sense to move to a standalone service that can be managed independently? [1] - https://github.com/mozilla/fxa-auth-server/issues/738 [2] - https://github.com/mozilla/fxa-auth-server/wiki/Service-discovery-API [3] - https://bugzilla.mozilla.org/show_bug.cgi?id=1003708 [4] - https://github.com/mozilla/fxa-oauth-server/issues/187
Flags: needinfo?(stomlinson)
(In reply to Shane Tomlinson [:stomlinson] from comment #11) > Are we going to keep adding new entries because it's the only > discovery system Firefox currently has? I hope not, because that implies Mozilla is building these additional services, and I want us to not do that :) Doing web extensions via this mechanism was a mistake IMO (ie, we should have worked out how to use the existing storage servers) On the other hand though, I can see a "sync.next server" within a couple of years, and I guess that maybe "Notes" would qualify too? > If so, does it make > sense to move to a standalone service that can be managed > independently? From my naive and distant POV, I don't expect enough churn here to make the creation of a new service worthwhile (although obviously you may have concerns I don't understand which would make it attractive)
> From my naive and distant POV, I don't expect enough churn here to make the creation of a new service worthwhile I agree, I don't feel like we're "there" yet w.r.t. using a separate service for this. Although FWIW that "services" would basically be a static JSON file that we update every once in a while. In retrospect it may have made more sense for this config info to live on the sync service rather than on FxA, because that's really what defines the necessary parts here (i.e. use this storage server, which requires tokens from this authorization server). > Doing web extensions via this mechanism was a mistake IMO (ie, we should have worked out how to use the existing > storage servers) I agree here too FWIW - not through any fault of Kinto, but the complexity of having something that the user perceives as a part of sync be backed by a separate service to the rest of sync, has produced quite a lot of edge-cases.
(In reply to Ryan Kelly [:rfkelly] from comment #13) > I agree here too FWIW - not through any fault of Kinto, but the complexity > of having something that the user perceives as a part of sync be backed by a > separate service to the rest of sync, has produced quite a lot of edge-cases. Perhaps it's too late for this, can a Sync related service discovery endpoint be added to the Sync service somehow?
I think it's too late for that - and TBH, I'm not sure I agree that the sync service should have that endpoint - I don't see how it would help things like Notes, or, in the far future, Mentat. It would also have the side-effect of more tightly coupling the client FxA and Sync code - we'd need to hit a sync service before we could determine how to log in to FxA.
TBH, I have a hard time feeling very strongly about saying "no, we shouldn't do this."
:markh - What sort of timeline are we looking at here?
Flags: needinfo?(markh)
(In reply to Shane Tomlinson [:stomlinson] from comment #17) > :markh - What sort of timeline are we looking at here? There's no urgency at all - we just want to remove the foot-gun we saw in bug 1462615.
Flags: needinfo?(markh)

Webext storage now uses the same sync endpoint as the other synced data types, so I think we can close this out.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.