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

Had to go to 0.0.0.0:8080 since the local subdomain isn't by default setup on Linux #94

Open
pimterry opened this issue Sep 18, 2023 · 7 comments

Comments

@pimterry
Copy link
Member

Just extracting this out as a separate issue:

OT: But I had to go to the webserver using 0.0.0.0:8080 since the local subdomain isn't by default setup on Linux, is that something the dev has on their computer ?

Originally posted by @stuaxo in #93 (comment)

Can you explain more detail about what you mean by this @stuaxo?

The normal URL you want to use is http://local.httptoolkit.tech:8080 which is a public DNS record, it shouldn't require local configuration - it's just a DNS record that resolves to 127.0.0.1.

It's only better than localhost in that it avoids some restrictions from Auth0 (and some other components I think) around using localhost addresses for local login - you should also be able to just use localhost:8080 if you like, really the only big issue is that login won't work correctly.

@stuaxo
Copy link

stuaxo commented Sep 18, 2023

Ah, I think I was making an assumption why this didn't work, I was behind a VPN inside a virtual machine (trying to look at things I was running in the same VM).

@pimterry
Copy link
Member Author

Ah, yes, that'll do it!

I actually realised another reason this might cause issues by the way: the server only allows connections from known origins (to avoid any risk of local XSRF - where other sites you visit on your machine access the localhost API) and 0.0.0.0 won't satisfy that. The allowed hosts are listed here. If you can't use the local addresses, you'll want to modify the list of allowed origins in your local server accordingly.

I'll leave this open for the minute, assuming this is still causing you issues, but do please share if you find a nice solution to this for your setup, or let me know if you're still stuck on this.

@stuaxo
Copy link

stuaxo commented Sep 18, 2023

Yeah it might be that - TBH, until I get further with getting the other things working it's a low priority.

❯ curl http://local.httptoolkit.tech:8080/
curl: (6) Could not resolve host: local.httptoolkit.tech

^ Both inside and outside my qemu ubuntu vm, with vpn off, and outside, in OSX, the host.

I guess it's possible that DNS is cached from where I had the work VPN on.

@pimterry
Copy link
Member Author

I guess it's possible that DNS is cached from where I had the work VPN on.

Possible I suppose, although even the fact that this doesn't resolve within your VPN is surprising to me!

As far as I know it should be accessible everywhere, checking from remote testers like https://dnschecker.org/#A/local.httptoolkit.tech does seem to show it resolving to 127.0.0.1 correctly on a wide variety of sources.

@stuaxo
Copy link

stuaxo commented Sep 18, 2023

Yeah, I'm not in some low connectivity place, I'm in London and I live next door to the local phone exchange, my fibre goes past one house then into it.

@mitchcapper
Copy link
Contributor

Some DNS servers filter out internal only IP blocks for external dns requests for 'security' that might extend to 127.0.0.1.

@stuaxo
Copy link

stuaxo commented Sep 27, 2023

I can try installing on my personal laptop, which runs amd64 ubuntu and see what happens there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants