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

[pimterry]

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 https://github.com/httptoolkit/httptoolkit-ui/issues/93#issuecomment-1722456094

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]

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]

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]

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]

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]

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]

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

[stuaxo]

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