Closed Bug 1620084 Opened 5 years ago Closed 4 years ago

Add Access-Control-Allow-Origin: * to public XPI files from AMO

Categories

(Cloud Services :: Operations: AMO, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: robwu, Assigned: wezhou)

References

()

Details

If I understand this correctly, the original github issue requested to set Access-Control-Allow-Origin: * for both addons.mozilla.org and addons.cdn.mozilla.net domains.

Is this safe to do?

Do we have any content that we do NOT want to set Access-Control-Allow-Origin: * for either domain?

(In reply to :wezhou from comment #1)

If I understand this correctly, the original github issue requested to set Access-Control-Allow-Origin: * for both addons.mozilla.org

Not AMO in its entirely, but only public XPI files. I think that the AMO part is better handled in addons-server itself, since it knows whether a xpi is supposed to be public. Seems like it could be added at https://github.com/mozilla/addons-server/blob/b0f6f466cd63d3957152ecc6177e36fbe8af99f1/src/olympia/versions/views.py#L107

and addons.cdn.mozilla.net domains.

Is this safe to do?

Adding Access-Control-Allow-Origin: * enables other websites to directly read the content of the resource, which is fine for static public content such as xpi files.

Do we have any content that we do NOT want to set Access-Control-Allow-Origin: * for either domain?

As mentioned, almost everything on addons.mozilla.org should NOT have Access-Control-Allow-Origin. For the purpose of this bug, let's concentrate on the CDN. I'll post a note in the bug about the header on AMO.

Assignee: nobody → wezhou

When will those CORS headers be added?

I'm still not seeing Access-Control-Allow-Origin: * in

curl -H 'Origin: https://example.com' -I https://addons.cdn.mozilla.net/user-media/addons/717783/extension_source_viewer-1.6.5-an+fx.xpi
curl -H 'Origin: https://example.com' -I https://addons-dev-cdn.allizom.org/user-media/addons/502867/bookmarks_organizer-3.0.1-fx.xpi
Flags: needinfo?(wezhou)

I've applied the change in -dev environment, and it seems to be working.

$ curl -H 'Origin: https://example.com' -I https://addons-dev-cdn.allizom.org/user-media/addons/502867/bookmarks_organizer-3.0.1-fx.xpi?bust
HTTP/1.1 200 OK
Content-Type: application/x-xpinstall
Content-Length: 97149
Connection: keep-alive
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Cache-Control: max-age=86400
Content-Security-Policy: default-src 'none'; report-uri https://addons-dev.allizom.org/__cspreport__
Date: Tue, 12 May 2020 22:15:29 GMT
Expires: Wed, 13 May 2020 22:15:29 GMT
Last-Modified: Wed, 05 Jun 2019 12:39:48 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Cache: Miss from cloudfront
Via: 1.1 916b3636f0e5533b1181c2f24120881f.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: HIO50-C2
X-Amz-Cf-Id: 66XSaFmZjn7tLQAtwyO4xBau_NPd6PYtZwvNzqI9dHSVkCH3QaghsQ==

We plan to apply it to -stage and -prod in a week or two if no regression is found in -dev.

Flags: needinfo?(wezhou)

A month has passed, was there anything that blocked the release?

Flags: needinfo?(wezhou)

There were https://bugzilla.mozilla.org/show_bug.cgi?id=1638386 and another fxa related issue that both had to do with AMO's nginx proxy layer. We had to back out the changes made for this ticket in order to test changes made for those two.

Now that issues in those two tickets have been stabilized, I re-deployed the changes for this ticket to -dev and -stage.

Please test in -dev and -stage and let us know if it works as expected.

Flags: needinfo?(wezhou)

Stage works:

$ curl -H 'Origin: https://example.com' -I https://addons-stage-cdn.allizom.org/user-media/addons/1002632/adblocker_for_youtubetm-1.5.0.6-an+fx.xpi
HTTP/1.1 200 OK
Content-Type: application/x-xpinstall
Content-Length: 31225
Connection: keep-alive
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
...

Dev does not:

$ curl -H 'Origin: https://example.com' -I https://addons-dev-cdn.allizom.org/user-media/addons/502867/bookmarks_organizer-3.0.1-fx.xpi
(response without Access-Control-Allow-Origin: *)

Prod does not either:

$ curl -H 'Origin: https://example.com' -I https://addons.cdn.mozilla.net/user-media/addons/717783/extension_source_viewer-1.6.5-an+fx.xpi
(response without Access-Control-Allow-Origin: *)

Dev works for me,

$ curl -H 'Origin: https://example.com' -I https://addons-dev-cdn.allizom.org/user-media/addons/502867/bookmarks_organizer-3.0.1-fx.xpi
HTTP/1.1 200 OK
Content-Type: application/x-xpinstall
Content-Length: 97149
Connection: keep-alive
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Cache-Control: max-age=86400
Content-Security-Policy: default-src 'none'; report-uri https://addons-dev.allizom.org/__cspreport__
Date: Fri, 12 Jun 2020 17:56:47 GMT
Expires: Sat, 13 Jun 2020 17:56:47 GMT
Last-Modified: Wed, 05 Jun 2019 12:39:48 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Cache: Miss from cloudfront
Via: 1.1 44cd593d82a2d200a94217033c614c6a.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: SEA19-C1
X-Amz-Cf-Id: q2CQQu-4l9dPw4G36eQeZti5D_KqmtokV9P4mh1sUgwVY3IAksM_dw==

Prod doesn't work is expected because we haven't pushed it to -prod yet (pending -stage and -dev verification).

Strange, I do really see something different (no CORS on dev, fetching through AMS):

$ curl -H 'Origin: https://example.com' -I https://addons-dev-cdn.allizom.org/user-media/addons/502867/bookmarks_organizer-3.0.1-fx.xpi
HTTP/1.1 200 OK
Content-Type: application/x-xpinstall
Content-Length: 97149
Connection: keep-alive
Accept-Ranges: bytes
Content-Security-Policy: default-src 'none'; report-uri https://addons-dev.allizom.org/__cspreport__
Last-Modified: Wed, 05 Jun 2019 12:39:48 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains
Cache-Control: max-age=86400
Date: Sat, 13 Jun 2020 14:14:53 GMT
Expires: Sun, 14 Jun 2020 14:14:53 GMT
X-Cache: RefreshHit from cloudfront
Via: 1.1 f9d671af272d3b5b3c683203ae8f4cc8.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: AMS54-C1
X-Amz-Cf-Id: cRhyD_vAbBSaBGIj_Mx6PsAE_emil-TAsiG8GV56U93lsG3fchCafA==

Maybe you happened to hit a cached object? What if you add a query string to the end of the url to bust the cache, and also try multiple times?

I still see the Access-Control-Allow-Origin: * header in -dev environment.

-dev now works as expected. It was likely a stale cache. When I experienced the issue, I also tried appending ? to see if it makes a difference, and it didn't.

This is now deployed to -prod.

$ curl -H 'Origin: https://example.com' -I https://addons.cdn.mozilla.net/user-media/addons/717783/extension_source_viewer-1.6.5-an+fx.xpi?foo=202007151
HTTP/1.1 200 OK
Content-Type: application/x-xpinstall
Content-Length: 210657
Connection: keep-alive
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Cache-Control: max-age=86400
Content-Security-Policy: default-src 'none'; report-uri https://addons.mozilla.org/__cspreport__
Date: Wed, 15 Jul 2020 18:31:23 GMT
Expires: Thu, 16 Jul 2020 18:31:23 GMT
Last-Modified: Tue, 05 Jun 2018 21:15:06 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Cache: Miss from cloudfront
Via: 1.1 112d82578d402a38d8d02e8b857617e1.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: SEA19-C2
X-Amz-Cf-Id: t2c3vZg5Bso7XRfv6SPHOvSq-TTPM1_K3uUwbhTTkZJ6SQM91vSB_Q==
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.