Addons-server: Include link to developer agreement page in corresponding API error

[Vinnl]

Is this a feature request or a bug?

Bug.

What is the current behavior?

I guess the problem might be on the server-side, but I'm not sure where to report that... Anyway, my CI server has been signing and publishing new versions of my extension for quite a while now, successfully. Trying it again today suddenly turned up the following error after running web-ext sign --artifacts-dir web-ext-artifacts --channel=unlisted --id={***} --api-key=*** --api-secret=***:

Error: Received bad response from the server while requesting https://addons.mozilla.org/api/v3/addons/%7B82c27c82-29f7-477c-8588-6255c1b59a2a%7D/versions/0.1.27build242630620/

status: 403
response: {"detail":"Before starting, please read and accept our Firefox Add-on Distribution Agreement as well as our Review Policies and Rules. The Firefox Add-on Distribution Agreement also links to our Privacy Notice which explains how we handle your information."}

What is the expected or desired behavior?

At least for a link to https://addons.mozilla.org/en-US/developers/addon/api/key/ to be present, along with a message indicating why it had to be signed again - or not requesting me to sign it again.

It appears this did not affect just me: https://stackoverflow.com/questions/56338055/where-i-should-accept-firefox-add-on-distribution-agreement

Version information (for bug reports)

• Firefox version: 67.0.3
• Your OS and version: Ubuntu 18.04
• Paste the output of these commands:

node --version && npm --version && web-ext --version v10.15.3 6.4.1 3.1.0

[diox]

Hi,

This was technically intended behavior: we updated the developer agreement and therefore required everyone to accept it again. Unfortunately as you noticed we didn't make it clear that it had been updated and the error message is missing a link. Sorry about that!

I'm transferring the issue to addons-server where it belongs as it's a server-side issue.

[diox]

People are still running into this whenever we update the policies. We still want the permission to fail and a 403 to be returned, we just want it to be more informative when using the API. The problem is, the message is shared between the API and developer hub. The flow in the code is this:

• In devhub/permissions.py, IsSubmissionAllowedFor uses UploadRestrictionChecker which checks a few restriction classes
• If the user hasn't accepter the latest developer agreement, it will fail the check
• Before returning False, self.message is set to checker.get_error_message(), which comes from the error_message property of the first failing restriction
• That message ends up in detail property of the 403.

So to fix it, one needs to pass something indicating that we're in the API when retrieving the message or instantiating the UploadRestrictionChecker, and add a short sentence explaining to visit the api key page with a link to it to unblock the developer *when the error is coming from DeveloperAgreementRestriction. This will probably require some refactoring of the restriction classes, maybe adding a mixin to share a common way to fetch the error message that would accept a parameter indicating that we're using the API, instead of just a error_message property.