Add Access-Control-Allow-Origin: * to public XPI files from AMO
Categories
(Cloud Services :: Operations: AMO, enhancement)
Tracking
(Not tracked)
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?
Reporter | ||
Comment 2•5 years ago
|
||
(In reply to :wezhou from comment #1)
If I understand this correctly, the original github issue requested to set
Access-Control-Allow-Origin: *
for bothaddons.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.
Comment 3•5 years ago
|
||
In https://github.com/mozilla/addons-server/issues/9118 I'll cover the application part, but we'll still need that header for requests to https://addons.cdn.mozilla.net/user-media/addons/* which are served directly from nginx using https://github.com/mozilla-services/cloudops-deployment/blob/master/projects/amo/puppet/modules/amo_proxy/templates/nginx.addons.conf.erb
Updated•5 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
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
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.
Reporter | ||
Comment 6•4 years ago
|
||
A month has passed, was there anything that blocked the release?
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.
Reporter | ||
Comment 8•4 years ago
|
||
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).
Reporter | ||
Comment 10•4 years ago
|
||
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==
Assignee | ||
Comment 11•4 years ago
|
||
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.
Reporter | ||
Comment 12•4 years ago
|
||
-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.
Assignee | ||
Comment 13•4 years ago
|
||
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==
Description
•