Ipfs-companion: Use Web UI version from IPFS Node

[lidel]

Context

Every IPFS Node provides :5001/webui endpoint on the API port. It redirects to the latest 'blessed' CID that can be loaded from :5001/ipfs/{cid}. For security reasons only hardcoded CIDs can be loaded from API port.

Right now IPFS Companion ships with hardcoded version of Web UI, and that version can be bigger than the one at :5001/webui.

Companion can't load it from API port as it is not on the whitelist, so it loads it from the Gateway instead. That comes at a price of having two separate Origins and falling under CORS limitations. We don't want people to add CORS headers, as it would allow allow any website loaded from Gateway port to execute arbitrary requests on API port. Instead, we remove CORS check on webui path by supressing Origin header in requests made from :8080/ipfs/{blessed_webui_cid} (Gateway) to :5001 (API).
That way we keep CORS check from anything else on Gateway port.

Why we did this? It made it possible for us to iterate and ship new Web UI without waiting for new go-ipfs release (which took multiple months at the time).

Proposed change

We are now in maintenance mode where regular go-ipfs releases are expected and webui itself is much more stable now.

It is time to:

• now: switch to /webui provided by go-ipfs (or js-ipfs) as the new default in Companion
  
  
  
  • PoC in PR: https://github.com/ipfs-shipyard/ipfs-companion/pull/737
  
  
• future: provide opt-in option for Companion users to load latest Web UI from :5001/ipns/webui.ipfs.io (requires ipns path to be added to API port whitelist in GO and JS)
  
  
  
  • PoC PR for Companion adding opt-in option: https://github.com/ipfs-shipyard/ipfs-companion/pull/738
  
  
  • PoC PR with discussion for go-ipfs: https://github.com/ipfs-shipyard/ipfs-companion/issues/736
  
  
  • PoC PR with discussion for js-ipfs: https://github.com/ipfs/js-ipfs/pull/2281
  
  

cc @olizilla (https://github.com/ipfs-shipyard/ipfs-webui/issues/1038#issuecomment-494000620)

[olizilla]

PR to go-ipfs to allow /ipns/webui.ipfs.io is go! https://github.com/ipfs/go-ipfs/pull/6530

[lidel]

• PR to switch Companion to /webui: https://github.com/ipfs-shipyard/ipfs-companion/pull/737
• PR to provide opt-in option for Companion users to load latest Web UI from :5001/ipns/webui.ipfs.io: https://github.com/ipfs-shipyard/ipfs-companion/pull/738
• PR to js-ipfs: https://github.com/ipfs/js-ipfs/pull/2281

[hacdias]

Should IPFS Desktop do the same too?

[hacdias]

Actually we can't. Many IPFS Desktop settings depend on the Web UI settings page. So, if the Web UI is only available when the daemon is on, then we can't access the settings. Unless we move Desktop specific options to the menubar itself as we're planning initially. It's basically a bunch of checkboxes.

[lidel]

Update:

• ipfs-companion
  
  
  
  • we will switch to loading webui from http://127.0.0.:5001/webui/ (API port) when #853 ships, all hacks related to "blessing" webui on gateway port will be removed
  
  
  • opt-in for loading latest webui from webui.ipfs.io.ipns.localhost:8080 is tracked in https://github.com/ipfs-shipyard/ipfs-companion/issues/860
  
  
• ipfs-desktop
  
  
  
  • I believe that in the long term it will be easier to stop shipping webui with ipfs-desktop and opening it in regular browser, or at least opening version from the API port. As mentioned above, desktop-specific preferences could be reimplemented as "Settings" submenu, decoupling Desktop from specific versions of WebUI. Tracked in https://github.com/ipfs-shipyard/ipfs-desktop/issues/1389