IPFS UI + HTTPs API are always pointing to port 80

[koalalorenzo]

Version information: 0.4.13

Type: Bug

Severity: Medium

Description:

When I am exposing the API behind a reverse proxy via HTTPS (nginx), the API call coming from the /webui interface are all failing as they are trying to get to port :80. In the logs of the browser it looks like this:

GET https://ipfs-api.myawesomewebsite:80/api...

What should I do to allow the UI to talk to the HTTPS correctly?
If I am disabling HTTPS it works perfectly.

To reproduce you can spin up a container, set up nginx to point :443 to :5001. Even with a fake certificate you will see the problem by browsing to https://localhost/webui.

(clones ipfs/kubo#4488 as this probably is the right place to submit the issue)

[Stebalien]

Preliminary warning: Please do not expose your API to the public internet.

It looks like this may have already been fixed (#602). We've recently updated the webui version in the go-ipfs master; would you mind building go-ipfs from git and trying that?

[danc86]

I tried master (commit 3d8aa07) built as QmULQD1iBBkxWkzb7nsyxpLqivjdfp4D1w2ctC8wRz8jJD. It's definitely different, but not fixed :-)

It seems to have the opposite problem now. I see Firefox blocking the AJAX requests like this:

Blocked loading mixed active content “http://ipfs.djc.id.au:443/api/v0/id?stream-channels=true”

Note port 443 but scheme http.

[koalalorenzo]

Is it possible to define this value (port, protocol, domain/ip, hash of the UI) in a env variable or somewhere in the conf? That would solve the problem and allow us to test more versions easily

[hacdias]

@danc86 @koalalorenzo could you please try the branch api-local and let me know if it works correctly?

[danc86]

I built commit b2dc3ad as QmZ8QuzSiF5mfJSYbAA6JWBENmYsYo3vzrSPtZxHKqPxSo. It still has the same problem, tries to access http://hostname:443/... It looks like you are intentionally slicing off the final char of window.location.protocol, what's up with that? Why not just use window.location.protocol as is?

[hacdias]

@danc86 the protocol variable always ends with : which is not wanted by this function.

[danc86]

Oh I see, makes sense. So it looks like it should work... does that mean I did something wrong when I built QmZ8QuzSiF5mfJSYbAA6JWBENmYsYo3vzrSPtZxHKqPxSo ? I just re-ran npm run build after checking out the branch.

[danc86]

All the js is minified and there are no source maps, so the browser debugger is useless :-(

[olizilla]

Fixed in #639 and the soon to be released Web UI v2 allows you to set your api address.

[travnewmatic]

salutations ipfs team!

using https://dist.ipfs.io/go-ipfs/v0.4.17/go-ipfs_v0.4.17_linux-amd64.tar.gz

able to load most of the webui, but it cant finish loading everything because its trying to pull from http://domain.tld:443/api/v0/

current relevant nginx config:

location /webui {
    proxy_pass http://127.0.0.1:5001/webui;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
}
location /ipfs {
    proxy_pass http://127.0.0.1:5001;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
}

identical to ipfs/kubo#4488 (comment)

[olizilla]

👋 v2 of the Web UI is out, which is a significant re-write. It'll be released with v0.4.18 of go-ipfs. You can also try out a recent build at https://webui.ipfs.io

In general, the Web UI expects accessed via 127.0.0.1, on the same port as the API. There is currently no access control or authentication for the http API, so it is not advised that you proxy access to it to the public internet. See #836

[lidel]

@travisperson

As Oli said, current Web UI (v2.1.1) should be accessed only from localhost.

In case people with similar problem find this issue in the future, additional notes below.

---

If you want to expose public HTTP gateway (similar to these), the nginx config from #611 (comment) does not look right:

• You are exposing :5001 which is the API port.
  • It gives admin access to your node. You usually don't want to expose it to the internet without encryption and authorization.
• Instead, try to expose /ipfs/ and /ipns/ from :8080 which is the read-only HTTP Gateway port
  • "safe" parts of /api are also exposed on :8080 but webui does not work with that yet, and just as @olizilla mentioned, we track that in Make Web UI work with the read-only API #835

If you want to use Web UI with remote node today:

• expose API port on localhost via ssh tunnel

If you really know what you are doing and really want to expose API port to the internet:

• Add location /api and ensure it is using :5001
• 💢 It MUST have access controls such as password or client certificate in front of it.
  • 💢 Without safeguards in place anyone an be admin of your node