Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore gateway redirect for CORS XHRs in Firefox #511

Merged
merged 3 commits into from
Jul 3, 2018

Conversation

lidel
Copy link
Member

@lidel lidel commented Jul 2, 2018

This PR restores gateway redirect for CORS XHR in Firefox via late redirect in onHeadersReceived and closes #436.

Context for why CORS XHR were not redirected until now can be found in #436 (comment) and upstream Bug #1450965.

In short, onBeforeRequest can't redirect anything when CORS XHR is processed, otherwise it will trigger false-positive CORS error. Good news is that onHeadersReceived is executed long after CORS validation happens in Firefox, and allows us to cancel original connection and do a late redirect right after response headers arrive.

This is the best we can do until upstream Bug #1450965 is addressed.

Additional Notes:

  • The original outgoing request to the public gateway has to happen :(
    I raised privacy concerns in the upstream bug.
  • Good news is that we only need to read response headers before connection is aborted. The overhead is minimal and I believe it is worth it: enables us to reach feature-parity with Chrome and removes dapp developer confusion that was caused by different redirect behaviors in Firefox and Chrome.

Jean-François Millet, 1857, Oil on canvas
Developers look for an efficient workaround in WebExtension API
Jean-François Millet, 1857, Oil on canvas

lidel added 2 commits July 3, 2018 00:05
Context for CORS XHR problems in Firefox:
#436

In short, onBeforeRequest should not change anything, as it will trigger
false-positive CORS error.  onHeadersReceived is after CORS validation
happens, so its ok to cancel and redirect late.

This is not ideal, as there is an outgoing request to the public
gateway, and we need to read response headers before connection is
aborted, but we can't do better than that until
https://bugzilla.mozilla.org/show_bug.cgi?id=1450965 is resolved.
@lidel lidel added the P1 High: Likely tackled by core team if no one steps up label Jul 3, 2018
@olizilla
Copy link
Member

olizilla commented Jul 3, 2018

💯 bonus points to @lidel for the issue report on bugzilla with minimal working extension to demonstrate the issue, and art lolz in the PR.

@@ -65,7 +68,7 @@ function createRequestModifier (getState, dnsLink, ipfsPathValidator, runtime) {
if (request.url.includes('/api/v0/add')) {
for (let header of request.requestHeaders) {
if (header.name === 'Connection') {
console.log('[ipfs-companion] Executing "Connection: close" workaround for https://github.com/ipfs/go-ipfs/issues/5168')
console.warn('[ipfs-companion] Executing "Connection: close" workaround for go-ipfs/issues/5168')
Copy link
Member

@olizilla olizilla Jul 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: logs with urls in are great, let's keep it

Copy link
Member

@olizilla olizilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lidel lidel merged commit e51cf4c into master Jul 3, 2018
@lidel lidel deleted the fix/cross-origin-xhr-firefox branch July 3, 2018 13:12
lidel added a commit that referenced this pull request Jul 5, 2018
Dnslink lookup is disabled by default, but if user opted-in to it,
many websites were broken due to invalid gateway redirects.

This change fixes regression introduced by:
#511
and adds tests to guard against the problem in future.
lidel added a commit that referenced this pull request Jul 5, 2018
Dnslink lookup is disabled by default, but if user opted-in to it,
many websites were broken due to invalid gateway redirects.

This change fixes regression introduced by:
#511
and adds tests to guard against the problem in future.
lidel added a commit that referenced this pull request Jul 5, 2018
Dnslink lookup is disabled by default, but if user opted-in to it,
many websites were broken due to invalid gateway redirects.

This change fixes regression introduced by:
#511
and adds tests to guard against the problem in future.
lidel added a commit that referenced this pull request Jul 5, 2018
Dnslink lookup is disabled by default, but if user opted-in to it,
many websites were broken due to invalid gateway redirects.

This change fixes regression introduced by:
#511
and adds tests to guard against the problem in future.
lidel added a commit that referenced this pull request Jul 5, 2018
Dnslink lookup is disabled by default, but if user opted-in in latest version websites were broken due to false-positive late gateway redirects of XHR requests.

This PR  fixes dnslink regression introduced by #511
and adds tests to guard against the problem in future.

Some deeper refactoring is due, but that is something for separate PR.
I want to land this PR as soon as possible, so that dnslink works again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

Successfully merging this pull request may close these issues.

gateway redirect messes up CORS headers on firefox
2 participants