Signing API client versioning

[wagnerand]

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.

[diox]

I think this should be done through the User-Agent, and perhaps sign-addon and web-ext versions should be present if applicable.

So, a request from sign-addon from an unknown 3rd party would look like:
User-Agent: sign-addon/x.y

A request from web-ext would look like:
User-Agent: web-ext/w.y, sign-addon/x.y

[eviljeff]

@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?

[wagnerand]

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.

[eviljeff]

If we're going with User-Agent are there any changes we need to make right now in addons-server? It seems like a feature we'd need to implement if in the future there is an incompatible change?

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 User-Agent (i.e. we'd warn on generic user agents). In either case I presume we're blocked on a change in webext (is there an issue filed for the changes there?)

[stale]

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.

[eviljeff]

@wagnerand after mozilla/web-ext#2538 lands and the release version of web-ext starts sending web-ext/1.23 as the user agent, what should addons-server do, exactly? (if anything, right now)

[wagnerand]

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.

[eviljeff]

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 can fire a statsd pings so a grafana dashboard can be created, sure.

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.

Can you link to the web-ext issue for that feature? This seems like a later issue we'd work on once web-ext already required it (and the stats showed was widely used)

[wagnerand]

Can you link to the web-ext issue for that feature? This seems like a later issue we'd work on once web-ext already required it (and the stats showed was widely used)

I believe that's mozilla/web-ext#2497

[eviljeff]

Can you link to the web-ext issue for that feature? This seems like a later issue we'd work on once web-ext already required it (and the stats showed was widely used)

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 web-ext maintainers can weigh in. Another blocker would be the --use-submission-api becoming a non-experimental option, imo.

[wagnerand]

Can you link to the web-ext issue for that feature? This seems like a later issue we'd work on once web-ext already required it (and the stats showed was widely used)

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 web-ext maintainers can weigh in. Another blocker would be the --use-submission-api becoming a non-experimental option, imo.

mozilla/web-ext#2543

[ioanarusiczki]

@eviljeff
I tried a Postman request for a version upload using the signing API -> was successful , this is the version

but I don't know what to do from here. Can you add some str ?

[eviljeff]

@eviljeff I tried a Postman request for a version upload using the signing API -> was successful , this is the version

but I don't know what to do from here. Can you add some str ?

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 web-ext versions. Only web-ext user agents though. (And the release version of `web-ext doesn't send the header yet)

So STR would be something like:

• use Postman (or some other tool that can set the HTTP_USER_AGENT header) to simulate what future web-ext will do, to submit an add-on via /api/v4/signing/
• make sure the header "HTTP_USER_AGENT": "web-ext/9999.1234" is sent with the request (anything web-ext/<combination of digits and .> should be matched)
• repeat with one of the addon submission api endpoints (it's the final create that's captured, not the xpi upload)
• ask someone with access to grafana to check the user agent has been counted (e.g. me)

[ioanarusiczki]

@eviljeff

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"

[eviljeff]

@eviljeff

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"

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 User-Agent

Also https://addons-dev.allizom.org/api/v5/addons/upload/ with "HTTP_USER_AGENT:web-ext/1.2"

This is the xpi upload endpoint, so it's not captured. Only the endpoints that create new add-ons or versions.

[ioanarusiczki]

@eviljeff

web-ext/1234.9999 at create with https://addons-dev.allizom.org/api/v5/addons/
web-ext/1.3 with https://addons-dev.allizom.org/api/v4/addons/{a42af60a-fd42-43d5-bf1b-f34302917b2a}/versions/4.0.5.5/
web-ext/12.21 with https://addons-dev.allizom.org/api/v5/addons/addon/
web-ext/9.99 with https://addons-dev.allizom.org/api/v5/addons/addon/623330/versions/

[eviljeff]

The debugging log statements indicated that the real User-Agent header value is being removed by Cloudfront (even though these requests wouldn't be cached by Cloudfront because they're authenticated). We will need to change something to forward the user agent header values if we are going to continue to use this strategy to log web-ext versions.

[eviljeff]

logged https://mozilla-hub.atlassian.net/browse/SVCSE-888 for SRE to make the appropriate change

[eviljeff]

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 User-Agent of 123.456? I can see if it shows up on https://earthangel-b40313e5.influxcloud.net/d/PisVfMBnz/amo-add-on-submissions

[eviljeff]

(I'll close this issue once SRE have confirmed it's been deployed to prod too)

[ioanarusiczki]

@eviljeff I sent 2 requests with the new submission API - User-Agent: webext/123.456

[ioanarusiczki]

@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

[eviljeff]

@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 web-ext/123.456 - the other two are webext/123.456 (note the missing -). It needs to be an exact match for web-ext/<numbers and .s> for it to be captured and sent along.