Suggest: use window.location to get host and port for API, make easy for visit from other machine

[alx696]

Expose API, Allow CORS:

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Credentials": [
        "true"
      ],
      "Access-Control-Allow-Methods": [
        "PUT",
        "GET",
        "POST"
      ],
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },
  "Addresses": {
    "API": "/ip4/0.0.0.0/tcp/5001",
    "Announce": [],
    "Gateway": "/ip4/0.0.0.0/tcp/6001",
    "NoAnnounce": [],
    "Swarm": [
      "/ip4/0.0.0.0/tcp/4001",
      "/ip6/::/tcp/4001"
    ]
  }

Visit webui from other machine. I must use localStorage.setItem('ipfsApi', '/ip4/node_ip/tcp/5001') to change the API. And its not work when use domain name.

Why not use window.location.hostname to get the host, window.location.port to get the port?

Port of webui always same as API port. Visit http://192.168.1.6:5001/webui, means: i need to use /ip4/192.168.1.6/tcp/5001 API. This is in line with expected behavior. And no need: Is your API on a port other than 5001? set form.

Wrong gateway address when click a mp4 file

Click Files Tab, then click mp4 file. webui use http://0.0.0.0:6001/ipfs/QmY8Xhcn8JS79QwJXCW95Lbqp4EoJap9pqfaAFGyRfjSyz as source:

<video controls="" class="mw-100 bg-snow-muted pa2 br2"><source src="http://0.0.0.0:6001/ipfs/QmY8Xhcn8JS79QwJXCW95Lbqp4EoJap9pqfaAFGyRfjSyz"></video>

Its better to use:

const geatewayPort = getGatewayPortFromConfig();
const gateway = `${window.location.protocol}//${window.location.hostname}:${geatewayPort}/ipfs/${qm}`

[thelamer]

I am running into this trying to embed in docker, from a security standpoint I understand the logic waterfall to assume localhost.

I think the best approach might be to just make special exceptions first on a connection failure to 127.0.0.1:5001 here and try the origin as the window.location.hostname with port 5001 along with the full origin hostname with port (currently it is trying the same port as the webUI for the /webui ipfs option):

https://github.com/ipfs-shipyard/ipfs-webui/blob/20be9638f9db39d86285b3901c171b2425741b87/src/welcome/WelcomePage.js#L61

Then when reading the config to set api and gateway here:

https://github.com/ipfs-shipyard/ipfs-webui/blob/ef0110faf02b6cc36490ebd5ec65522a9915d4af/src/bundles/config.js#L31-L39

In the case of reading from the config if the config has anything set to 0.0.0.0 there should be an if stanza that falls back to the window.location.hostname as 0.0.0.0 will never work.

[lidel]

Since https://github.com/ipfs-shipyard/ipfs-webui/pull/1563 we delegate API detection to ipfs-provider, which by default will try accessing API on the same origin: https://github.com/ipfs-shipyard/ipfs-provider/blob/3e275b3aa79788a3adce1e3fb3c0b1fbfff0d972/src/providers/http-client.js#L43-L53 This is a basic heuristic, more advanced logic could be implemented in userland.

There is a bunch of related issues: https://github.com/ipfs-shipyard/ipfs-webui/issues/1490, https://github.com/ipfs-shipyard/ipfs-webui/issues/836#issuecomment-670699378, feels like we could tackle all of them in a single PR, cleaning up the UX of using API of a remote node. See my comment at https://github.com/ipfs-shipyard/ipfs-webui/issues/1490#issuecomment-671633602