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

No longer works in Firefox Nightly #622

Closed
da2x opened this issue Nov 16, 2018 · 6 comments
Closed

No longer works in Firefox Nightly #622

da2x opened this issue Nov 16, 2018 · 6 comments
Assignees
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@da2x
Copy link

da2x commented Nov 16, 2018

The IPFS Companion stopped working one–three weeks ago in Firefox Nightly.

It can’t connect to IPFS Desktop anymore. IPFS is listening on the expected ports, however. IPFS Companion still works in Chromium.

I’ve tried reinstalling IPFS Companion and have tested with older versions all the way back to 2.4.0.

Confirmed issue on Firefox Nightly on macOS 10.14 and Windows 10.1809.

@da2x
Copy link
Author

da2x commented Nov 16, 2018

OK, the admin interface is returning 403 Forbidden.

The difference between Chrome and Firefox is that Firefox appends a Origin: moz-extension://{extension-installation-id} HTTP request header. If I remove that header from Firefox’s requests, everything starts working again.

@lidel lidel added the kind/bug A bug in existing code (including security flaws) label Nov 16, 2018
@lidel
Copy link
Member

lidel commented Nov 16, 2018

Thank you for reporting!

Interesting. This is basically Firefox version of #615 (which we fixed in #616).

In short, Chrome was adding Origin: null to fetch made from webextension background pages and acted as sort of false-positive trigger for CORS validation producing 403 Forbidden.

Seems that Firefox Nightly started setting Origin: moz-extension://{extension-installation-id} (which is better than null) but that produces the same error. Will probably should apply similar fix here.

@da2x
Copy link
Author

da2x commented Nov 16, 2018

Heads up: I’d expect this behavior to change in Firefox. The internal UUID they send is unique and persistent per installation. It would allow for user tracking.

Edit: upstream issue.

@da2x
Copy link
Author

da2x commented Nov 16, 2018

Correction: it’s been like this for a year according to bugz#1405971. I’m not sure why this issue only started affecting IPFS now.

lidel added a commit that referenced this issue Nov 16, 2018
@ghost ghost assigned lidel Nov 16, 2018
@ghost ghost added the status/in-progress In progress label Nov 16, 2018
lidel added a commit that referenced this issue Nov 16, 2018
@ghost ghost removed the status/in-progress In progress label Nov 16, 2018
@lidel
Copy link
Member

lidel commented Nov 16, 2018

@da2x shipped a fix in v2.6.1.12130 (Beta), give it a try! :)
We now compare URL.origin in value-agnostic way, so it should work even if Firefox changes the Origin value to something else (eg. if they switch to 'null', like in Chromium)

@da2x
Copy link
Author

da2x commented Nov 16, 2018

Works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Development

No branches or pull requests

2 participants