Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alx696 opened this issue Jan 16, 2019 · 2 comments
Labels
effort/hours Estimated to take one or several hours exp/wizard Extensive knowledge (implications, ramifications) required kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Milestone

Comments

@alx696
Copy link

alx696 commented Jan 16, 2019

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}`
@alx696 alx696 changed the title API Address always 127.0.0.1, Easy to fix but why not Suggest: use window.location to get host and port, make easy for visit from other machine Jan 16, 2019
@alx696 alx696 changed the title Suggest: use window.location to get host and port, make easy for visit from other machine Suggest: use window.location to get host and port for API, make easy for visit from other machine Jan 16, 2019
@thelamer
Copy link
Contributor

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
Copy link
Member

lidel commented Aug 11, 2020

Since #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: #1490, #836 (comment), 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 #1490 (comment)

@lidel lidel added this to the v2.11 milestone Aug 11, 2020
@lidel lidel added exp/wizard Extensive knowledge (implications, ramifications) required effort/hours Estimated to take one or several hours kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked labels Aug 11, 2020
@jessicaschilling jessicaschilling modified the milestones: v2.11, v2.12 Sep 1, 2020
@lidel lidel modified the milestones: v2.13, v2.14 Apr 13, 2021
@SgtPooki SgtPooki moved this to To do in IPFS-GUI (PL EngRes) Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/hours Estimated to take one or several hours exp/wizard Extensive knowledge (implications, ramifications) required kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

4 participants