[go: nahoru, domu]

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

Inspect view: "View on IPFS Gateway" still points to the ip-address, not to .localhost #1490

Closed
RubenKelevra opened this issue May 10, 2020 · 3 comments · Fixed by #1559 or #1591
Closed
Assignees
Labels
effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Milestone

Comments

@RubenKelevra
Copy link

Describe the bug
On the inspect view there's a button labled with "View on IPFS Gateway", which still points (in my case) to 127.0.0.1/ipfs/<CID> instead of <CID>.ipfs.localhost.

Screenshots
Screenshot_20200510_162131-1

Desktop (please complete the following information):

  • OS: Linux
  • Browser: Brave
@RubenKelevra RubenKelevra added the need/triage Needs initial labeling and prioritization label May 10, 2020
@jessicaschilling
Copy link
Contributor

@lidel and/or @rafaelramalho19 -- can you please have a look? Thank you!

@jessicaschilling jessicaschilling added exp/intermediate Prior experience is likely helpful effort/hours Estimated to take one or several hours kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked and removed need/triage Needs initial labeling and prioritization labels May 12, 2020
@rafaelramalho19
Copy link
Contributor

I was able to replicate it 👍

Thank you for reporting this Ruben, I will check it out.

@lidel
Copy link
Member
lidel commented Aug 10, 2020

@rafaelramalho19 After additional analysis I am afraid we need to revert ipfs/kubo#1559 – it won't work in offline contexts and private swarms (without ipfs-companionloading from public gateway will hang forever and then timeout)

We also can't just blindly swap 127.0.0.1 with localhost because localhost subdomains are not guaranteed to be enabled and work everywhere (https://github.com/ipfs/go-ipfs/issues/7527)

Additional heuristic should be added in the place where gatewayUrl is read from node's config:

  • If gateway is 127.0.0.1:port
    • send GET request for <knowncid>.ipfs.localhost:port (eg. empty unixfs dir)
      • If response in HTTP 200, then subdomains work in current browser
        • replace 127.0.0.1:port with localhost:port in "View on IPFS Gateway"
  • We could have something similar if gateway is 0.0.0.0, then we replace it with window.location.hostname or replace both host and port with window.location.host

How does that sound?

@lidel lidel reopened this Aug 10, 2020
@lidel lidel added this to the v2.11 milestone Aug 11, 2020
lidel added a commit that referenced this issue Aug 28, 2020
jessicaschilling added a commit that referenced this issue Sep 1, 2020
* fix: view in gateway url now validates if url is acessible

* chore: add gateway error message

Co-authored-by: Jessica Schilling <jessica@protocol.ai>

* chore: move from memoizee to p-memoize

* chore: fix config bundle async calls

* chore: fix config bundle async calls

* chore: fix config bundle async calls

* chore: update empty dir cid

Co-authored-by: Marcin Rataj <lidel@lidel.org>

* chore: remove gatewayurl override from the settings page

* feat: separate gateway bundle

* chore: code optimization

* feat: prefer subdomain gw on localhost

#1490 (comment)
Closes #1490

Co-authored-by: Jessica Schilling <jessica@protocol.ai>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
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/intermediate Prior experience is likely helpful kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
None yet
4 participants