Reconsider silly "security" practicies

[dsvi]

According to the issue:
#591
The WebUI has weird "security protection mechanism" in the form of hardcoded 'localhost' strings in it's javascript.
This really is a weak security feature (to put it mildly) and causes more problems than it solves. In fact, it solves none.
I do believe this should be reconsidered.

[daviddias]

Hi @dsvi, there is, in fact, a conversation happening about API tokens for apps like the WebUI and others, see: ipfs/kubo#1532

Consider joining the conversation. The current mechanism is not the best, but it is not creating issues other than the one that it is there for, limiting access to the webui from an outside node.

Remember, Webui is just a webpage, you can always change that value and also change the value in go-ipfs and use that special node for yourself :)

[dsvi]

Hi!
"it is there for, limiting access to the webui from an outside node."
You don't seem to get the point. The web UI is accessible from an outside node anyways. Even now with the hardcoded localhost in it. (if you have configured the go-ipfs appropriately) The problem is, the Web UI is useless this way. Which renders ipfs browser extensions useless, if you don't run ipfs on the same computer, on which you are browsing.
The API tokens are unrelated issue. API is already accessible outside. No reason to make the WebUI unusable.

[DiagonalArg]

Yes, this is really an issue for me. I am VPN'ing through the server on which IPFS is running. localhost refers to my laptop, so I need to get to the ui via http://ServerIP:5001/webui.

As a comparison, the torrent client transmission provides a "-a" option for allowed IP's. I give it localhost and the IP address of the server. It also allows a "-t" option to set a username ("-u") and a password ("-v"). You might want to consider this approach.

This issue also appears in #628, #637, and #591.

[myfingerhurt]

1. Change your API address has your wish like this,
   10.9.8.9 is my VPN remote address which hosts the IPFS.

 "Addresses": {
    "API": "/ip4/10.9.8.9/tcp/5001",
    "Announce": [],
    "Gateway": "/ip4/127.0.0.1/tcp/8080",
    "NoAnnounce": [],
    "Swarm": [
      "/ip4/0.0.0.0/tcp/4001",
      "/ip6/::/tcp/4001"
    ]
  },

2. Then run this in your console:

$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin "[\"*\"]"

# The following two lines are not necessary, but you know in case you need it.
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Credentials "[\"true\"]"
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods "[\"PUT\", \"POST\", \"GET\"]"

3. Open a browser you will be finally able to access your IFPS

http://10.9.8.9:5001/webui

---

But see 0 peers?

1. Restore "API": "/ip4/127.0.0.1/tcp/5001",

2. This is still needed.

$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin "[\"*\"]"

3. Redirect port 5001 to localhost
   10.9.8.11 is your VPN address on remote VPS, here I'm using zerotier.

sudo iptables -t nat -A PREROUTING -d 10.9.8.11 -p tcp --dport 5001 -j DNAT --to-destination 127.0.0.1:5001

# The following line is just for the reference
sudo iptables -t nat -A OUTPUT -d 10.9.8.11 -p tcp --dport 5001 -j DNAT --to-destination 127.0.0.1:5001

4. Forward zt0 to localhost

sudo sysctl net.ipv4.ip_forward=1
sudo sysctl -w net.ipv4.conf.zt0.route_localnet=1 

5. Open a browser http://10.9.8.9:5001/webui
   everything should be working.

[olizilla]

Closing in favour of #836