Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow downstream firefox builds to self-select API keys to /country #151

Closed
alexcottner opened this issue Apr 3, 2024 · 3 comments · Fixed by #152
Closed

Allow downstream firefox builds to self-select API keys to /country #151

alexcottner opened this issue Apr 3, 2024 · 3 comments · Fixed by #152

Comments

@alexcottner
Copy link
Contributor

As a part of the MLS sunset process, we are migrating the functionality of one endpoint to classify-client for backwards compatibility: /v1/country. Firefox currently uses this to identify the current region the browser is in (for preferences and defaults).

Previously, downstream builds of Firefox (ex: package maintainer builds for linux distros) would use their MLS key to reach this endpoint. Maintainers and downstream devs would need to apply for a key, Mozilla would need to approve and issue the key, and then MLS would need to authorize every request coming in against the set of known keys.

Going forward we would prefer to allow downstream builds to self-identify. We will allow requests to /v1/country that provide an API key that are either:

  1. An existing known MLS key for a Firefox build, including existing downstream keys
  2. Follow the pattern /^firefox\-downstream\-\w{1,40}$/ . Example: firefox-downstream-debian_13_0.
@mostlygeek
Copy link

mostlygeek commented Apr 3, 2024

For the regex pattern, it may be useful to have a way to communicate with the source of the requests. Perhaps we can consider the format being:

  1. it's an email address, like: id:firefox-location@somelinuxbuild.org
  2. it's a TXT dns record, like id:firefox-location.somelinuxbuild.org <-- must resolve to an email address?

This would give us communicate with the source for some reason.

@alexcottner
Copy link
Contributor Author

Requiring an email address or domain to be provided is good.

But I don't think we should/could have true validation. If downstream build is popular but we're unable to verify that record one day for whatever reason (maybe they moved domains), then that would leave existing users unable to hit the endpoint.

@alexcottner
Copy link
Contributor Author

After speaking with @mostlygeek , we're going to stick with the original plan of using simple strings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants