This repository was archived by the owner on Nov 6, 2023. It is now read-only.
Use upgradeToSecure when possible#15157
Merged
Hainish merged 2 commits intoApr 28, 2018
EFForg:masterEFForg/https-everywhere:masterfrom
bcyphers:add-upgrade-to-secure-supportbcyphers/https-everywhere:add-upgrade-to-secure-supportCopy head branch name to clipboard
Merged
Use upgradeToSecure when possible#15157Hainish merged 2 commits intoEFForg:masterEFForg/https-everywhere:masterfrom bcyphers:add-upgrade-to-secure-supportbcyphers/https-everywhere:add-upgrade-to-secure-supportCopy head branch name to clipboard
Hainish merged 2 commits into
EFForg:masterEFForg/https-everywhere:masterfrom
bcyphers:add-upgrade-to-secure-supportbcyphers/https-everywhere:add-upgrade-to-secure-supportCopy head branch name to clipboard
Conversation
Use Firefox's new upgradeToSecure flag instead of standard URI rewrites when applying simple rulesets. Should fix issue with CORS blocking certain HTTPS rewrites (EFForg#49). Use browser.runtime.getBrowserInfo, a firefox-only API, to determine browser compatibility.
Collaborator
|
/cc @Hainish |
Contributor
Member
|
I'll review this tomorrow. |
Hainish
suggested changes
Apr 25, 2018
| function getUpgradeToSecureAvailable() { | ||
| if (typeof browser !== 'undefined') { | ||
| return browser.runtime.getBrowserInfo().then(function(info) { | ||
| var version = info.version.match(/^(\d+)/)[1]; |
Member
|
Thank you! |
Collaborator
|
verified using a master build at 5f6cec7, I'm going to do a mass close for issues tagged as CORS. |
This was referenced Apr 28, 2018
Closed
Closed
This was referenced Apr 28, 2018
Contributor
|
@gloomy-ghost can you confirm that a mass close is appropriate given lack of Chrome support at this time? |
Collaborator
|
@bardiharborow see #49 (comment), it has been solved in Chrome for a long time |
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #49.
Builds on #15092.
In Firefox, cross-origin resource sharing (CORS) requests that are approved for http urls are sometimes
blocked after being rewritten to https. Firefox has recently added a new option to webRequest.BlockingResponse, upgradeToSecure, which performs a simple http --> https rewrite. This branch tries to use that flag instead of a standard rewrite whenever (1) the rewrite is trivial and (2) the browser is Firefox 59+.
Can be tested on this website: http://shop.decatorevista.ro/
With the current version of the extension in Firefox, a few calls to maxcdn.bootstrapcdn.com will be blocked, breaking styles on the page. This branch allows them to be rewritten successfully. Turn on logging in the background page and look for "onBeforeRequest returning upgradeToSecure: true" messages, and filter outgoing requests to cdnjs.cloudflare.com to make sure they're being rewritten to https.
This PR uses the browser.runtime.getBrowserInfo API to determine the type and version of the browser. Since browser.* APIs aren't in chrome, it first checks whether
browseris defined, then checks the browser name and version number accordingly. Unfortunately, since all browser.runtime.* APIs are implemented as promises, I had to add a new initialization function to the background page that figures out whether onBeforeRequest is available on load and saves it as a global(ish) variable.