Enable CORS for /api/v4/file/ endpoints

[nothingisdead]

Describe the problem and steps to reproduce it:

After signing an addon using the v4 API, it is impossible to download it in any environment restricted by CORS, even when sending a correct Authorization header.

I followed the instructions on http://addons-server.readthedocs.io/en/latest/topics/api/signing.html, and was able to sign my addon. However, when using fetch to request the download_url, the request is blocked by CORS restrictions. It looks like the /api/v4/file/... endpoints do not send the CORS header to allow API clients to download the file in CORS-enabled environments. To complicate matters, it doesn't seem like it's even possible to redirect the user to the download_url for unlisted addons, since there is no way to provide the Authorization JWT header.

What happened?

I got the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://addons.mozilla.org/api/v4/file/[file_id]/[base_filename]?src=api. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
TypeError: NetworkError when attempting to fetch resource.

What did you expect to happen?

I expected to get a response.

Anything else we should know?

The CORS preflight OPTIONS request indicates that Access-Control-Allow-Origin should be set to *, but the actual GET request doesn't send that header.

OPTIONS request headers:

GET request headers:

[eviljeff]

Did you try this before when it was the /v3/ API? (Trying to establish if we broke something with the recent API upgrade or if it's always been like this)

[nothingisdead]

I just tried it, and I get the same result on the /v3/ API.

[diox]

The question is, did it work before ? The introduction of the v4 API is recent, and we're trying to determine if it used to work before that.

Note that even though that does look like a bug, the signing API isn't really designed for being used in a browser. As you noted, following redirections is an issue when you have to pass authorization.

[nothingisdead]

The question is, did it work before ? The introduction of the v4 API is recent, and we're trying to determine if it used to work before that.

As far as I can tell, it has the same behavior on the /v3/ API. Do you mean before that?

Note that even though that does look like a bug, the signing API isn't really designed for being used in a browser.

It is perhaps an odd use case... my goal is to write a serverless app and provide additional functionality via an optional WebExtension. It is a password management app, so I wanted to give users the ability to easily build and sign their own version of the extension if they choose.

As you noted, following redirections is an issue when you have to pass authorization.

If CORS was enabled, I think if I disable following redirects using fetch, I can read the first response header, get the X-Target-Digest header and the redirect location, and make a second request to download -> verify -> serve the file to the user via a Blob URL.

[diox]

As far as I can tell, it has the same behavior on the /v3/ API. Do you mean before that?

I (we) mean on /v3/ API before we introduced the v4 API. That is, on v3 API before May 17th.

Your use-case is a bit unusual but I agree it would work if CORS was working properly, so we should definitely fix it.

[nothingisdead]

I (we) mean on /v3/ API before we introduced the v4 API. That is, on v3 API before May 17th.

Ah, sorry. That I don't know. :( Thanks for looking into this.

[nothingisdead]

I think nothingisdead/addons-server@bec7e68 should fix this. I didn't submit a pull request because I don't have an environment set up to test the change... let me know if you want me to.

BTW this will enable CORS on all HttpResponseSendFile responses... not sure if that's safe or not.

[diox]

It might work as a hack but we apply CORS globally to all views, so if it's not working we need to understand why instead of hiding the problem.

[diox]

Ah, I think I see what's happening. It's not a new issue, and I don't think this patch would fix it. The problem is that view is relying on X-Accel-Redirect to let nginx serve the file. Most of the headers we set are ignored as nginx is taking over and returning content on its own.

We'll see what we can do but it's unlikely to be fixed soon.

[nothingisdead]

Oh I see. That makes sense... thanks again.

[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.