Ipfs-companion: Can't Connect to Local Node in Chrome with Beta versions v2.5.1.11970 or v2.5.1.12010

[5310]

As of v2.5.1.11970 (Beta) and v2.5.1.12010 (Beta) IPFS Companion can't connect to my local node under Chrome, and yet Firefox works just fine.

• Switching to the custom gateway instantly shows that the gateway is offline and switches to the internal js-ipfs node by default.
• Disabling automatic switching keeps the extension in external mode, showing the gateway and API address correctly but version and peer appears offline, and fails to work.
• As tested on Firefox with the extension as well as just by directly accessing the local node's API from the same Chrome instance, everything is working fine on my end.

Versions:

• Xubuntu 18.04 LTS
• Chrome 70.0.3538.77 (Official Build) (64-bit)
• Firefox 63.0 (64-bit)
• Go-IPFS 0.4.18
• IPFS Companion
  
  
  
  • v2.5.1.11970 (Beta)
  
  
  • v2.5.1.12010 (Beta)
  
  

When I enabled error logging for the extension in Chrome I get the following:

• Fresh install with default automatic external/internal switching enabled:
  
  
  
  • :warning: Error while ipfs.swarms.peers: SyntaxError: Unexpected number in JSON at position 4
  
  
  • Chrome's extension error log doesn't hang.
  
  
• Thereafter, with automatic mode disabled and switched to external node (but with DNSLink enabled by default):
  
  
  
  • :exclamation: Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/
  
  
  • Context: dist/background/background.html
  
  
  • Stack Trace: dist/bundles/backgroundPage.bundle.js:2 (readDnsLinkFromTxtRecord)
  
  
  • Chrome's extension logging page immediately hangs the tab, and reaches 100% CPU usage.
  
  
  • This is clearly related to the DNSLink functionality which has also always worked for me even before it was enabled by default.
  
  
  • Disabling DNSLink removes the error and doesn't hang the error logging page.
  
  
• Thereafter, with DNSLink disabled, but still on the custom node.
  
  
  
  • Just the JSON error as before, and nothing else.
  
  

[5310]

I just tested out the extension with a separate Chrome profile, and it fails similarly there as well.

[lidel]

Thank you for reporting this.

I was able to reproduce this with vanilla go-ipfs 0.4.18 (fresh install, default config without custom HTTP headers):

$ docker run --rm -it -p 8080:8080 -p 4001:4001 -p 127.0.0.1:5001:5001 ipfs/go-ipfs:v0.4.18

The Problem

Seems that Chrome (or one of recent changes in Companion) removed our ability to execute this workaround, and the old issue is back:

| :anger: go-ipfs without CORS (default) | :ok_hand: go-ipfs with CORS |
| ---- | ---- |
| | |

Workaround

Until we fix this upstream, a quick fix is to manually add CORS header via commandline:

$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

After daemon restart, it should work again.

@5310 are you able to confirm if the workaround works for you?

[5310]

@lidel I've just set the CORS config as instructed and it's now connecting under Chrome as before!

[lidel]

@5310 FYI I've just released bugfix as v2.6.0.12060 (Beta) v2.6.1 (Stable) and it should work again even with vanilla go-ipfs config :+1:

[5310]

Updated, reverted, and working flawlessly! :bowing_man:

[lidel]

Awesome! Thanks again for super helpful info in https://github.com/ipfs-shipyard/ipfs-companion/issues/615#issue-378147694 it saved me a lot of time :)