Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.localhost Domains

inclouds.space

Post reply on HN
Print view View original

191–200 of 212 posts

Re: .localhost Domains

#191

Post by peterldowns »

bestham wrote: post #174
peterldowns wrote: post #68

If you’re interested in doing local web development with “real” domain names, valid ssl certs, etc, you may enjoy my project Localias. It’s built on top of Caddy and has a nice CLI and config file format that you can commit to your team’s shared repo. It also has some nice features like making .local domain aliases available to any other device on your network, so you can more easily do mobile device testing on a rea…

There is also mkcert by Filippo Valsorda (no relation to mkcert.org) at https://github.com/FiloSottile/mkcert

Yup, mkcert is used by caddy which is used by localias :)

Re: .localhost Domains

#192

Post by peterldowns »

CodesInChaos wrote: post #170
sangeeth96 wrote: post #79

Earlier quoted context omitted.

It's mentioned in the README: - If Caddy has not already generated a local root certificate: - Generate a local root certificate to sign TLS certificates - Install the local root certificate to the system's trust stores, and the Firefox certificate store if it exists and an be accessed. So yes. I had written about how I do this directly with Caddy over here: https://automagic.blog/posts/custom-domains-with-https-for-…

But is this an unconstraint root, or does it use name constraints to limit it to localhost domains/IPs? And how does it handle/store the private key associated with that root?

What's your threat model here? The way this works is that on your development machine, localias (through caddy/mkcert) generates a root cert and the per-site certs and installs them to your development machine's trust store. All of the certs live entirely on your device and never leave. You have full control over them and can remove them at any time.

The certs and keys live in the localias application state directory on your machine:

    • tree /Users/pd/Library/Application\ Support/localias/caddy/pki/authorities/local/
    /Users/pd/Library/Application Support/localias/caddy/pki/authorities/local/
    ├── intermediate.crt
    ├── intermediate.key
    ├── root.crt
    └── root.key
The whole nicety of localias is that you can create domain aliases for any domain you can think of, not just ".localhost". For instance, on my machine right now, the aliases are:

    • localias list
    cryptoperps.local -> 3000
    frontend.test -> 3000
    backend.test -> 8080

Re: .localhost Domains

#193

Post by radlad »

AndyMcConachie wrote: post #162
radlad wrote: post #130

Earlier quoted context omitted.

RFC 8375 seems to have approved it specifically to use in Home Networking Control Protocol, though it also states "it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed. Rather, 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788]: local name service in residential homenets." The OpenWrt wiki on Homenet suggests th…

Check the errata for RFC 7788. .home being listed in it is a mistake. .home has never been designated for this purpose. home.arpa is for HNCP. Use .internal.

I simply quoted RFC 8375. It specifically called out that while RFC 7788 mentions ".home" (quoted below), it wasn't reserved, which ".home.arpa" aims to fix. But while you say "home.arpa is for HNCP", I also quoted RFC 8375 stating it's available for other uses as well.

> A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; [...]

Re: .localhost Domains

#194

Post by c-hendricks »

_odey wrote: post #155

Note: browsers also give you a Secure Context for .localhost domains. https://developer.mozilla.org/en-US/docs/Web/Security/Secure... So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).

> if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine

Won't `localhost:3000` and `localhost:3001` also both be secure contexts? Just starting a random vite project, which opens `locahost:3000`, `window.isSecureContext` returns true.

Re: .localhost Domains

#195

Post by stuaxo »

Nice, I've been wanting this - was just today talking about it.

Would be good to have the config all somewhere in my user's dir too.

Per user subdomains for their apps on localhost.

Re: .localhost Domains

#196

Post by sabslikesobs »

politelemon wrote: post #166

This feels like more work than necessary, I'm not seeing an advantage. Ideally any kind of dev setup should be as contained/localized as possible, but if I'm having to modify OS components, then that feels like sprawl. Or, it's like /etc/hosts but with extra steps.

Yes, I felt like this too. I like that it's cute and how it removes the need to inject ports into any "this is my URL" environment variables, but I agree it does sound like "sprawl." Browser bookmarks serve the same purpose.

Re: .localhost Domains

#197

Post by TingPing »

kbolino wrote: post #188
wutwutwat wrote: post #184

Earlier quoted context omitted.

1. not all browsers are the same they are all aiming to implement the same html spec 2. there is no official standard there literally is > A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification https://w3c.github.io/webappsec-secure-contexts/ 3. even if there was, standards are often ignored major browsers wouldn't be m…

Notably, assuming conformance to this standard, a browser might still not treat localhost domains as trustworthy if it has reason to believe they can be resolved remotely. However, I'm not sure in what environments this is likely to be the case, especially with browsers implementing their own DNS over HTTPS.

Recently browsers hardcode localhost to never resolve over dns.

Re: .localhost Domains

#198

Post by TingPing »

globular-toast wrote: post #187
jFriedensreich wrote: post #25

Chrome and i think Firefox resolve all .localhost domains to localhost per default, so you don't have to add them to the hosts file. I setup a docker proxy on port 80 that resolves all requests from .localhost to the first exposed port of that container (in order of appearing in the docker compose file) automatically which makes everything smooth without manual steps for docker compose based setups.

Source for this? Are you sure it's not your system resolver doing it?

There is a draft spec over it, Ill find it later, but they do hardcode it now and never touch dns.

Re: .localhost Domains

#199

Post by kevincox »

hardaker wrote: post #20

You might check out .internal instead which was recently approved [1] for local use. [1]: https://en.wikipedia.org/wiki/.internal

*.localhost is reserved for accessing the loopback interface. It is literally the perfect use for it. In fact on many operating systems (apparently not macOS) anything.localhost already resolves to the loopback address.

Re: .localhost Domains

#200

Post by _odey »

c-hendricks wrote: post #194
_odey wrote: post #155

Note: browsers also give you a Secure Context for .localhost domains. https://developer.mozilla.org/en-US/docs/Web/Security/Secure... So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).

> if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine Won't `localhost:3000` and `localhost:3001` also both be secure contexts? Just starting a random vite project, which opens `locahost:3000`, `window.isSecureContext` returns true.

This is used for scenarios where you don't want to hardcode port numbers, like when running multiple projects on your machine at the same time.

Usually you'd have a reverse proxy running on port 80 that forwards traffic to the appropoiate service, and an entry in /etc/hosts for each domain, or a catch all in dnsmasq.

Example: a docker compose setup using traefik as a reverse proxy can have all internal services running on the same port (eg. 3000) but have a different domain. The reverse proxy will then forward traffic based on Host. As long as the host is set up properly, you could have any number of backends and frontends started like this, via docker compose scaling, or by starting the services of another project. Ports won't conflict with eachother as they're only exposed internally.

Now, wether you have a use for such a setup or not is up to you.

Post reply on HN