-
Notifications
You must be signed in to change notification settings - Fork 41
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
Signing API client versioning #8685
Comments
I think this should be done through the So, a request from A request from |
@wagnerand can you give an example (assuming this is a current, rather than future problem)? Like, a version id (or range) of webext that is incompatible with a current AMO api feature? |
The concrete idea here is that this would allow us to require certain information to be passed by a developer. One of the biggest challenges we identified through metrics is missing source code submissions. Now that the API allows to provide that, one approach would be to add a new argument to web-ext that specifies either holds the source code package or states that sources are not needed. Obviously, only newer/future versions of web-ext would have this feature, so we need to be able to nudge users towards keeping web-ext up to date (also for other things like linting rules etc). The compatibility alignment is an abstraction of the problem that allows for more and future use cases. And in any case, it would be good to have insights on what versions of our client libraries developers are on so we can understand and assess support cycles. |
If we're going with Or if we want to start warning users about keeping up to date with webext and/or specify a user agent for non-webext uses, as soon as webext supports sending the custom |
This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions. |
@wagnerand after mozilla/web-ext#2538 lands and the release version of |
A good start would be to graph the stats on version numbers internally. Obviously we're only starting now to have that info, so many requests won't have it, but over time, that should change. We could also look into the use case I described above about source code submission. Specifically for the new submission API, we could require a newer web-ext version to make sure it supports the requirement for the developer to state that sources are either attached or not needed. |
We can fire a statsd pings so a grafana dashboard can be created, sure.
Can you link to the |
I believe that's mozilla/web-ext#2497 |
Ah. That would be a blocker to it - to actually allow sources to be uploaded - but it isn't going to enforce sources, or require the developer somehow confirm that sources aren't needed. Can you file an issue that details how you suggest that parameter would work so the |
|
If an add-on or version is successfully created via the signing or addon submission APIs then the user agent header is processed and we count So STR would be something like:
|
I sent https://addons-dev.allizom.org/api/v4/addons/{a42af60a-fd42-43d5-bf1b-f34302917b2a}/versions/4.0.5.4/ with "HTTP_USER_AGENT: web-ext/9999.1234" Another one with https://addons-dev.allizom.org/api/v5/addons/ and "HTTP_USER_AGENT:web-ext/123.456" Also https://addons-dev.allizom.org/api/v5/addons/upload/ with "HTTP_USER_AGENT:web-ext/1.2" |
Sorry, I gave the django name for the header - if postman doesn't support some generic way of specifying the user agent string, then the raw header is actually named
This is the xpi upload endpoint, so it's not captured. Only the endpoints that create new add-ons or versions. |
web-ext/1234.9999 at create with https://addons-dev.allizom.org/api/v5/addons/ |
The debugging log statements indicated that the real |
logged https://mozilla-hub.atlassian.net/browse/SVCSE-888 for SRE to make the appropriate change |
https://github.com/mozilla-services/cloudops-deployment/pull/4729 adds this to the appropriate SRE config files. I've confirmed it works on addons-dev. @ioanarusiczki can you test on stage with the |
(I'll close this issue once SRE have confirmed it's been deployed to prod too) |
@eviljeff I sent 2 requests with the new submission API - User-Agent: webext/123.456 |
@eviljeff I tried with the old signing API for https://addons.allizom.org/api/v5/addons/{5e840ca1-bbc8-4048-ab6b-ef5b082d16d7}/versions/5.0.0.6/ -> webext/123.456 |
From the logs, only one of these three requests seems to have been sent with |
In order to support and align compatibility between the signing API and clients like web-ext, this API should take a parameter with each call indicating the client application and version. When our own supported clients like web-ext make requests to the API, we can parse that information and make sure the client is compatible with it. Additionally, we can ensure that clients use a minimum version of web-ext for a particular signing API version or feature. Doing so will help ensure users are on recent versions and that requirements, recommendations or best practices for submission and signing can be shown to the user via web-ext.
The text was updated successfully, but these errors were encountered: