Open karmanyaahm opened 3 years ago
Thank you for reporting this @karmanyaahm
Quick thoughts:
Ideally, we would modify CSP to match redirect, making entire thing self-contained. Our browser extension is able to modify HTTP headers, but we need to check if that happens before CSP policy is executed by the browser context (and if the order is the same in Chromium and Firefox).
If that is not possible, alternative is to disable redirect-by-default when CSP header is detected, to avoid breaking pages by default, and requiring manual opt-in from the user.
window.ipfs
got deprecated (https://github.com/ipfs/in-web-browsers/issues/172)Update: this is limited to Firefox.
Describe the bug When a website includes a script that's hosted on an DNSLink domain, and has a restrictive Content Security Policy, the scripts fail to load, and the website doesn't function properly.
To Reproduce Steps to reproduce the behavior:
Expected behavior Go to the website and all the assets load. There is no CSP error in the console.
Desktop (please complete the following information):
Possible Solution Modify CSP to gateway. I used the Mozilla Laboratory extension to modify the CSP on the website. My IPFS Gateway is at http://127.0.0.1:8080, so I added
http://127.0.0.1:8080/ipns/*.cactus.chat
to the script and style CSP directives (in a real solution font-src etc. should also be added). only/ipns/*.cactus.chat
here because that's what the script-src and style-src already specified. IPFS Companion should do this automatically.Another solution would be to stop intercepting URLs when scripts and stylesheets are being loaded over IPFS.
Note - I'm not associated with cactus.chat I just noticed this problem with companion, so I'm making this bug report. Note 2 - related issues - #701 seems like the solution 2 that I said, but it seems to be closed and that behavior still doesn't happen? #624 's solution is to disable window.ipfs, but the toggle for that is locked and there seems to have been no progress on that?