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

Redirect to local gateway not working #1162

Closed
undyingwraith opened this issue Feb 18, 2023 · 3 comments · Fixed by #1163
Closed

Redirect to local gateway not working #1162

undyingwraith opened this issue Feb 18, 2023 · 3 comments · Fixed by #1163
Assignees
Labels
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

Comments

@undyingwraith
Copy link

undyingwraith commented Feb 18, 2023

This was also reported in https://twitter.com/unicomp21/status/1626244123102679041

Describe the bug
All i get is the error page of my local node not being reachable (it is). Even clicking on redirect to public gateway results in the same thing.

To Reproduce
Steps to reproduce the behavior:

  1. Navigate to 'ipfs.tech'
  2. Observe the error page

Expected behavior
The site to load through my local gateway (ipfs.tech.ipns.localhost:8080)

Desktop (please complete the following information):

  • OS: Win 10
  • Browser: Firefox
  • Version: go-ipfs v0.13.0

Additional context
It works fine if i disable the integration and navigate to 'ipfs.tech.ipns.localhost:8080' directly.

Im currently copying a lot of files from the disk the ipfs repo is on, pausing it doesnt seem to influence the behaviour.

Im currently not really well reachable so it might take some time till i can respond. If you need any additional info just ask.

@undyingwraith undyingwraith added the need/triage Needs initial labeling and prioritization label Feb 18, 2023
@welcome

This comment was marked as off-topic.

@whizzzkid whizzzkid added 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 Feb 21, 2023
@whizzzkid
Copy link
Contributor

Thanks for posting this issue @undyingwraith, At first I thought this was a regression from #1125, however, when trying to reproduce this issue I could not achieve the same results. The way this is designed to work is:

let's take your example (this was the previous experience)

  • companion checks with the node if the node is online (using the API).
  • if the node is online, the ipfs.tech -> http://ipfs.tech.ipns.localhost:<port>/
  • the page should load over local node.

Say you already have a page loaded in the browser from local node (or someone sent you a link) and node goes offline. (the new experience)

  • companion checks with the node if the node is online (using the API). It's not.
  • since the node is offline, recovery screen shows up. http://ipfs.tech.ipns.localhost:<port>/ -> ipfs.tech (public url)
  • since the node is not online, this should not redirect to the local node (this already worked).

What might be happening?

My hunch is the config in your extension is somehow causing a conflicting edge case. i.e. it reports the node as online when redirecting, but then reports as offline during the recovery logic. Would you be able to share your config settings, maybe there is an override I overlooked that. I think it might be the Automatic Mode button.

@whizzzkid
Copy link
Contributor

Ok I just confirmed, when automatic mode is off it results in the behaviour you just described. 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants