Skip to content
This repository was archived by the owner on Feb 12, 2024. It is now read-only.

IPFS node.on('start') not working correctly in Chrome #915

Closed
EthanHaley opened this issue Jul 18, 2017 · 9 comments
Closed

IPFS node.on('start') not working correctly in Chrome #915

EthanHaley opened this issue Jul 18, 2017 · 9 comments
Labels
kind/bug A bug in existing code (including security flaws) kind/support A question or request for support status/ready Ready to be worked

Comments

@EthanHaley
Copy link

I'm currently trying to run some of the examples available for IPFS, however the IPFS nodes don't seem to properly start in Chrome. I've tried both the transfer-files from this repo and the collaborative editing demo (https://github.com./ipfs-shipyard/shared-editing-demo) and in both cases the nodes start and demos work in Firefox, however trying to load them in Chrome produces no results. For transfer-files it just hangs on start, and the collaborative editing just leaves you typing in your own little text area in Chrome. Firefox nodes properly talk to each other and function as expected, however Chrome nodes don't talk to other Chrome nodes or Firefox nodes. It seems like a bug coming from Chrome but I'm not sure what is causing it exactly. Any information to help with this would be greatly appreciated.

@victorb
Copy link
Member

victorb commented Jul 18, 2017

Could you put a reproducible snippet here so we can try out? Also, listen for any errors and console.log them, include them here if they appear.

@EthanHaley
Copy link
Author

collabediting
transfer-files

This the code I am running. No errors are thrown. I have the console.log in the transfer to see if the code is hitting node.on('start'). All messages are output in Firefox, while just the first two console.log are outputted in Chrome, which is why I believe it to be an issue in node('start') on Chrome.

@victorb
Copy link
Member

victorb commented Jul 18, 2017

Could you add this as well, to see if there is any errors:

node.on('error', (err) => {console.log(err)})

@EthanHaley
Copy link
Author

errors

@victorb
Copy link
Member

victorb commented Jul 18, 2017

So DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV) seems to be the error that is being thrown here.

Short URL leads to: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

But I'm not sure what feature in js-ipfs or yjs / y-ipfs-connector that triggers this. From what URL are you running your example? Localhost?

@EthanHaley
Copy link
Author

I am running my example from a server that I am accessing via SSH. I added the IP address of the server to the gateway portion of the IPFS config in addition to localhost.

@daviddias daviddias added kind/support A question or request for support kind/bug A bug in existing code (including security flaws) labels Jul 19, 2017
@kareniel
Copy link

kareniel commented Jul 27, 2017

I ran into this issue just now. Worked fine on Firefox, but not on Chrome.
Turned out my development server (budo) served content at my machine's local IP by default (something like 192.168.0.100), while go-ipfs uses 127.0.0.1 for it's http endpoint.
I configured budo to serve from 127.0.0.1 instead and got it to work.

I think that Chrome considers your IPFS node's endpoint to be an insecure origin. http-server seems to be the dev server you're using, and I think it uses 0.0.0.0 as a default host address.You can use the -a option to pass it a different address. (for the collaborative editing demo, I think that would involve changing the start script in package.json to something like http-server -c-1 -p 12345 -a 127.0.0.1 public)

@daviddias daviddias added the status/ready Ready to be worked label Jul 27, 2017
@daviddias
Copy link
Member

Thanks for the precious insight @kareniel :)

@EthanHaley still hitting this issue?

@daviddias
Copy link
Member

@EthanHaley closing, let us know if you still see this problem.

MicrowaveDev pushed a commit to galtproject/js-ipfs that referenced this issue May 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug A bug in existing code (including security flaws) kind/support A question or request for support status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

4 participants