Skip CORS Anywhere for AMO-hosted add-ons in the web version #92
Comments
Rob--W
added a commit
that referenced
this issue
Jul 1, 2020
Verified with add-ons at addons-dev.allizom.org, but does not work with addons.mozilla.org yet, because the prod CDN still needs to be updated: https://bugzilla.mozilla.org/show_bug.cgi?id=1620084#c5
Rob--W
added a commit
that referenced
this issue
Mar 19, 2022
Domain fronting was originally introduced in #58 because Firefox 60 removed the ability to read data from AMO (https://bugzilla.mozilla.org/show_bug.cgi?id=1450649). Very recently, AMO's server migrated to another host, and the current domain front (reviewers subdomain) is no longer reachable at the same server. Consequently, the extension was no longer able to read XPI files because it looked at the wrong place. Although AMO supports CORS for public XPIs (#92), we still need to use domain fronting for non-public XPIs, such as XPIs from add-ons without a public listing on AMO, or XPIs only visible to reviewers. The services subdomain appears to be hosted on the same server as AMO.
Rob--W
added a commit
that referenced
this issue
Mar 28, 2022
- Rely on CORS instead of work-arounds for public XPI files from AMO (#92) - Add work-around for crx access in Brave (#91) - Support source viewing of extensions from Microsoft Edge (#95) - Remove web_accessible_resourced to avoid UUID leak (#100) - Correct 0-padding of hashes (#104) - Update jsbeautifier to v1.14.0 (#110) - Support source viewing of extensions from Thunderbird (#111) - Fix domain front of AMO in Firefox add-on (#115) - Recognize CRX3 files served by addons.opera.com (#118) - Opera only: Add work-around to access addons.opera.com (#119) - web only: Add crx keyword to input field for keyword search (#99) - web only: Avoid breakage of web version when an extension runs a script (#113) - Refactor: remove unsupported declarativeWebRequest path - Refactor: Use declarative page actions to show button.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The web version of crxviewer uses CORS Anywhere to read the source code of extensions.
In March, AMO already started to support CORS on publicly available XPI files: mozilla/addons#5875
Soon, the AMO CDN will also include CORS headers on such XPI files: https://bugzilla.mozilla.org/show_bug.cgi?id=1620084#c5
Once the last change has landed, the web version of crxviewer doesn't require CORS Anywhere for XPI files from AMO any more. Skipping CORS Anywhere would result in a better user experience, since the CORS Anywhere proxy doesn't need to be used any more.
Related: The Firefox add-on version doesn't use CORS Anywhere, but domain fronting as a work-around for the inability to read data from AMO. With the CORS response headers, domain fronting is not required any more for publicly readable XPI files hosted on AMO and its CDN. The domain fronting work-around should still be kept however, to make sure that cookies are included in the request for XPI files behind authentication (an alternative is to use the cookies API to manually fetch and add relevant cookies, but that would require more work and another permission).
The text was updated successfully, but these errors were encountered: