Allow custom address for the gateway

[hazae41]

Describe the bug
The gateway is set to http://0.0.0.0:8080/ while I'm connecting from an external computer through a VPN

This bug affects the app since content in not watchable directly in the WebUI

To Reproduce
Steps to reproduce the behavior:

1. Set your API address and gateway address to 0.0.0.0 (ip4) or :: (ip6)
   (1.1 Set your CORS allow-origin to "*")
2. Connect to the WebUI with an external computer
3. See that the gateway is the one from the config instead of the real (external) address

Expected behavior
We should be able to set a custom gateway address

[jessicaschilling]

@rafaelramalho19 - are you able to triage? Thank you!

[BunkerMelon]

@hazae41 have you been able to make any progress on this? My team has tried many different scenarios and are unable to set a custom gateway either

[hazae41]

@BunkerMelon No, sorry

[rafaelramalho19]

Requesting @lidel help on this, I tried looking into it but I have no ways right now to test it 😢

[lidel]

I don't believe there is a problem with webui – this looks like a misconfiguration:

1. The gateway at remote node is set to listen on ambiguous 0.0.0.0 (all interfaces).
2. This means the image in webui is embedded like this:

   <img src="http://0.0.0.0:8080/ipfs/{cid}" />

3. The browser maps 0.0.0.0 to the loopback device of the local machine. If there is no gateway running locally, the image fails to load.

---

@BunkerMelon @hazae41 Do you mind explaining what is your use case and how your network topology looks like?
Any reason why you are not loading webui from the API port at http://127.0.0.1:5001/webui ?

---

Anyway, generic advice if you want to access webui of a remote node: avoid loading it over public IPs and/or ambiguous 0.0.0.0.

Instead, create a tunnel (eg. SSH) that redirects 127.0.0.1:8080 and 127.0.0.1:5001 from your machine to respective ports at the remote machine running the IPFS node. That way you will be able to access API of remote node and its webui at http://127.0.0.1:5001/webui without compromising your security, nor need any additional workarounds.

[tgies]

We also need this capability. The go-ipfs Docker container, as distributed, manifests this issue. Not everyone is accessing an IPFS node running locally.

[hazae41]

@lidel

I host an IPFS daemon on a small server, which I connect through a VPN because it's more flexible than CORS headers.

I also use an IPFS daemon on my local machine, so I can't map 5001 and 8080 ports on it. And even if I could just map them to other ports, SSH mapping is still a workaround for something that should work out of the box.

Also, SSH mapping can't be done on every devices like iPhones or Android. Whereas connecting to a VPN and making a POST request can easily be done using automation apps.

[BunkerMelon]

We also need this capability. The go-ipfs Docker container, as distributed, manifests this issue. Not everyone is accessing an IPFS node running locally.

This is essentially the problem I am having as well, I am running an IPFS container on a SBC within the same network as the computer I am trying to access the WebUI from. The SBC is running Ubuntu server 18.04 so it isn't possible to access the WebUI on the same host..

[robert-hedler]

Hi Team. If i add this option: --net=host in the docker run command i am able to run the gateway on another ip than localhost or 127.0.0.1. But i guess that this is not the best way to fix this. I still trying other approach but no luck yet.

[lidel]

Thank you all, this is very useful feedback.
Understanding how people use webui against something other than the local node highlights gaps in current stack.

• In the short term, fix: view in gateway url now validates if url is acessible #1591 will add simple heuristic which:

  • tries to use Gateway address based on IPFS node config (Addresses.Gateway)
    • when more than one address is specified, the first address is used
    • performs get test, to confirm API is reachable
  • if using IPFS node fails (for one of myriad of reasons), falls back to public gateway at ipfs.io

  This way links and image previews will always work for everyone,
  but power users will be able to troubleshoot most of things on their own.

• Mid term, we could prioritize working with Core Impl. Working Group (go-ipfs/js-ipfs) to lift some Origin restrictions, and refine the heuristic in webui, making it easier to use remote node. Eg. by introducing native support for Basic Auth when accessed on non-localhost IP.

• Long term, API port needs proper access controls (tracked in API Tokens kubo#1532)

[robert-hedler]

Thanks. About the Basic Auth for non-localhost IPS, i set on NGINX reverse proxy this. integrate this into IPFS will be awesome 🥇

[BunkerMelon]

Thank you as well @lidel

Having it fall back to ipfs.io whenever it cannot reach the "local" IPFS node gateway on the network will work great for the time being.

Looking forward to testing these new implementations