webui incorrectly assumes "localhost" for the gateway

[kallisti5]

Describe the bug
The webui assumes "localhost" for the gateway, even though it was accessed on a non-localhost system.

To Reproduce
Steps to reproduce the behavior:

1. Access an IPFS gateway remotely
2. Go to 'explore'
3. Click on 'xkcd'
4. Pick a comic
5. Hover over 'View on IPFS Gateway'

Expected behavior
webui gateway host should default to the same host that the webui is accessed via.

Screenshots

Desktop (please complete the following information):

• OS: Arch Linux
• Browser: Opera

[hacdias]

@kallisti5 I agree that it may not be the expected result, but if it says localhost, because:

1. The configuration of Addresses.Gateway has that address listed there; and
2. The address is available from the machine you're browsing.

If you browse from a different machine, you'll see that only the public gateway will be visible. At least this is what I've been able to reproduce.

I'm not sure if we're supposed to change this behaviour. Right now, Addresses.Gateway can provide multiple addresses and we pick the first one to test. However, we can also change it so we test all of them and prioritize them by the order they show up in the configuration. So if localhost is the first and is available, that will be the one that shows. We can also see if the origin is present in Addresses.Gateway, and if so we try that first.

What do you think?

/cc @lidel

[lidel]

I'm leaning towards closing this issue, unless there is a bug or a feature request that solves UX problem.

@kallisti5 afaik you experienced go-ipfs' security feature that aims at preventing people from exposing RPC API port as a Gateway one by mistake.

Below some explainers.

RPC API at :5001/api/v0 is not Gateway

The webui assumes "localhost" for the gateway, even though it was accessed on a non-localhost system.

There is more to this. To be very specific, you opened webui from the RPC API port (:5001) which allows ipfs-webui access to unlimited, full admin-level /api/v0 without the need for setting CORS headers.

Loading webui from API port makes it work out of the box, no eed for setting CORS headers, but also opens the surface for misconfiguration – we don't want people to expose Admin RPC API to the internet. That is one of the reasons why go-ipfs does not allow arbitrary CIDs on its RPC API port. Only safelisted CIDs (ipfs-webui releases) are allowed, which protects people who mistake RPC API port for Gateway one. Arbitrary CIDs simply won't load.

How ipfs-webui finds the Gateway address

When ipfs-webui starts, it will try to find the best Gateway address, and use it for displaying previews in Files and the link on Explore screen mentioned here.

There are some smarts in here and here that make it "just work" in the browser:

• the first address from ipfs config Addresses.Gateway is read
  • if IP is 0.0.0.0 or 127.0.0.1 and subdomain on localhost is available, we replace hostname with localhost to ensure each CID root get own origin sandbox
  • we fetch bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss from the Gateway to confirm it works (could be offline, could be config misconfiguration, firewall, or CORS issue)
• if Addresses.Gateway can't be used, we fallback to public gateway as a last resort

@kallisti5 you probably have a gateway running on localhost on your local machine, that is why the web app decided to use it instead of a public gateway. If you want to use gateway from LAN, change the order in Addresses.Gateway and put LAN IP before local one.

Let us know if this solved your issue, or elaborate more what would be the behavior you expect.

[kallisti5]

No gateway running on my localhost. I have a machine on my network serving as a gateway for all of my systems and hosting around 200 GiB of content.

I feel like a lot of these issues are because the user stories are too rigid. A percentage of users much less than 100% will be running IPFS on an external machine.

• CID computation not happening locally in the client before sending data over the network to the api server making pinning data slow.
• Webui breaking down when accessed on anything except localhost (when the webui can be pointed at any api server address)

Most home networks (the most compelling place to run IPFS nodes hosting data) are behind a NAT, thus most home users are going to have "one IPFS node" since it's easy to tunnel IPFS through their router to a single machine.

Your user story assuming everyone running IPFS on their local machine doesn't scale to real world usage requirements.

As for security, sure.. anything on my network can access the api server. It's a private network so that's fine.

At the end of the day, users run into these mysterious issues, look at them as bugs, and move on from IPFS. I tried getting a bunch of techy users to mirror our repositories and ran into the same general complaints over and over.

[lidel]

Your user story assuming everyone running IPFS on their local machine doesn't scale to real world usage requirements.

Correct. ipfs-webui won't work for every setup.

ipfs-webui, as it is today, is limited by the current security model of go-ipfs RPC API and web browsers. It is not perfect, but makes webui work out of the box for Desktop users, and scales pretty well for server/remote nodes, as long you tie RPC API to localhost (eg. tunnel it over SSH, if you run it on a remote box).

The "webui power user group opening webui via LAN IP" has never been the core audience of ipfs-webui, and doing it means you will hit some problems in browsers (unencrypted HTTP traffic to a LAN IP is not a Secure Context, while localhost is).

This could change/improve in the future if go-ipfs adds some access controls for the RPC API (ipfs/kubo#1532), and/or when we have proper protocol handlers for ipfs:// (removing the secure context problems).

No gateway running on my localhost.

Ah, this sounds like a bug! But i don't believe it is.

If you have no Gateway on localhost, then the test (HTTP GET http://localhost:8080/ipfs/bafkqae2xmvwgg33nmuqhi3zajfiemuzahiwss) should fail and the link should point at a public gateway.

I suspect it does not fail because you have IPFS companion enabled, and it redirects the request to the correct gateway.

Mind testing again, but with IPFS Companion disabled?
It should fail to reach gateway and use public gateway instead of localhost.

[kallisti5]

I suspect it does not fail because you have IPFS companion enabled, and it redirects the request to the correct gateway.

Correct. IPFS companion is indeed installed and is configured for my gateway server at 192.168.1.80:8080

Mind testing again, but with IPFS Companion disabled?

Confirmed. The gateway changes from localhost to ipfs.io when companion is disabled. Ideally it would change to 192.168.1.80:8080 (my configured gateway in the companion), however ipfs.io would at least not be "broken" :-)

[kallisti5]

here's the ipfs companion config...

[SgtPooki]

@whizzzkid This issue seems to be related to ipfs-companion not respecting the configured local-gateway. Can you confirm?