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

Lcl.host: fast, easy HTTPS in your local dev environment

anchor.dev

Post reply on HN
Print view View original

31–40 of 101 posts

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#31

Post by wolfgang42 »

hackmiester wrote: post #28
orliesaurus wrote: post #25

Earlier quoted context omitted.

(IMHO) the lesson is that sometimes you're excited to tell the world about what you built, that you forget about some "other stuff" i.e. I don't think that the authors of this tool wanted to have developers be forced to use the latest version of their tool. It's probably that they didn't think about it when they wrote the code, but now they know and hopefully this gets fixed in the next release?

I just don't understand what the thing about "downloading everything as .gz" means. It's not like a gz is a rare file format, it seems like a totally reasonable format to download something in.

Having once made a similar mistake myself, I assume what they mean is that it was downloading everything as a .gz—that is, the browser was asking users “where would you like to save index.html.gz?” instead of showing the homepage. (This happens when you precompress a static site for performance, but forget to tell the server that gzip should be negotiated as a Content-Encoding instead of a Content-Type.)

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#32

Post by benburkert »

JimDabell wrote: post #13

Warning: This checks if it’s running the latest version and refuses to run if it isn’t up to date. They just released v0.0.16 15 minutes ago and the update hasn’t hit Homebrew yet, so it has completely disabled itself and won’t run. There doesn’t seem to be any option to skip the version check. So don’t use this unless you don’t mind it breaking randomly whenever there’s an update.

Sorry about that, we're working on switching this to a warning and not an error, that slipped by us before release. After the next update, it will only show a warning if you're not on the latest release.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#33

Post by its_stolt »

hartator wrote: post #23

Were some bugs that show only in the https version of the app?

These tend to manifest themselves when you have mixed content on the page or you're using CORS. For CORS the issues can surface due to running different rules for dev vs prod/stg.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#35

Post by peter_l_downs »

mholt wrote: post #15
peter_l_downs wrote: post #2

I like the interactive setup. I think this is solid but if you want something even faster and easier to use, try my project localias [0]. The parent project, lcl.host, has some annoying restrictions: > This CA has some restrictions though: it can only issue certificates for subdomains of lcl.host and localhost, but that’s all you need for local development. Localias, on the other hand, lets you use any custom domain…

Neat! I hadn't seen this before, and it uses Caddy :D

Yes! Thank you for making Caddy, it’s wonderful software and it was really easy to extend!

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#36

Post by nucleardog »

dspillett wrote: post #10
zikduruqe wrote: post #5

Earlier quoted context omitted.

You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert

I've always been a bit wary of a local trusted CA, especially with the signing cert on the same dev box as the certificates it signs which is how I've seen things done a lot. It feels like opening up a trust issue that could allow an uncooperative entity to play games with me… Maybe that is just paranoia from the practical jokes played back in CompSci at Uni! Admittedly an external attacker getting close enough to si…

The way I handle this in the dev tooling I put together is to run a totally separate browser profile that (1) trusts the certificate and (2) can only connect to localhost. It also launches with a totally different colour scheme.

With chrome, that's something like:

    google-chrome
        --user-data-dir="${HOME}/.config/ourlocaldev/google-chrome"
        --install-autogenerated-theme=85,63,9
        --host-rules="MAP * 127.0.0.1, EXCLUDE localhost, EXCLUDE fonts.googleapis.com, EXCLUDE fonts.gstatic.com"
        --ignore-certificate-errors-spki-list="0oKw9nasIS7qRQD1CYXe5bmi22/mnHjZP++f6G+VM88="
        "https://my.dev.thing"
This will launch a separate copy of chrome with a fresh/separate profile. It will have a different colour (RGB values set in there) so it's visually distinct when it's running and I don't get the windows mixed up. Any request made from the browser will be rewritten to connect to 127.0.0.1 (except a couple google font domains).

The danger if someone got their hands on my local key/cert is basically nil. They would only be able to MITM connections from this one specific browser window to localhost. And that browser is incapable of connecting to anything besides localhost. I can never accidentally open my banking site in there. Also fresh profile so no saved passwords, credit cards, or anything else.

(As an added benefit, I don't really need to worry about reconfiguring URLs for projects. If I open "testing.mysite.com" in that browser, it will force the connection to localhost, so I can just run my services at our test URLs and steal configs as-is from the testing environment. Taking it further, I then have a controller set up in k3s/Rancher Desktop that rewrites the service on all annotated ingresses to point to its own service, which runs nginx, which the controller then configures to proxy the requests on to the local service or the actual upstream testing service depending on whether the local container is running. It also configures CoreDNS to point the upstream URLs at the same proxy. End result is that from the browser or anything running in k3s you can hit our testing URLs and it will hit your local container if it's running or fall back to the testing environment if not.)

If you want to try the browser thing, you can generate the fingerprint for a certificate with:

    echo "" |
    openssl s_client -connect 127.0.0.1:443 -prexit 2>/dev/null |
    openssl x509 -pubkey -noout -in /dev/stdin |
    openssl pkey -pubin -outform der |
    openssl dgst -sha256 -binary |
    openssl enc -base64

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#37

Post by 8organicbits »

Wingy wrote: post #21

Why modify the trust stores with the personal CA? Is there any risk to just publishing a globally valid wildcard cert for *.lcl.host, since it always resolves to 127.0.0.1 anyway?

Some sites have tried this before, but I dont think they stay online long. The certificates are "leaked" when they are shared, so the CA will revoke them.

I think a better approach is to get a domain name and a Let's Encrypt certificate. There's lots of tooling for this, and it matches production. I built https://www.getlocalcert.net/ to act as free, Let's Encrypt compatible subdomain service specifically for these sorts of challenges.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#38

Post by chuckadams »

hk1337 wrote: post #29
afavour wrote: post #6

Earlier quoted context omitted.

> It surprises me how few people dev/test against HTTPS For dev at least it’s mostly because web browsers treat localhost as a special domain that gets the HTTPS treatment even when loaded over HTTP. I have set up local HTTPS certs before now, can’t remember exactly what required it. But I still load most web projects on localhost over HTTP just out of habit.

I've always thought the need for local HTTPS was unnecessary for at least 90% of the projects and brought no real value other than making the developer "feel" better. localhost with HTTP should be sufficient for most things. It's when you start doing stuff like "app.localhost" like what was mentioned in the article which, despite it having "localhost" is not the same as http://localhost . Develop basic in local and d…

There are a number of APIs, such as geolocation, that only work over https. It's also very common to accidentally generate non-https urls for assets, which is a bug most people would rather catch in local dev and not production when the browser refuses to fetch them.

I use traefik to serve my apps in dev, which generates self-signed certs by default if you don't hook it up to ACME. Slightly more cumbersome because it means clicking through a warning screen and disabling verification in CLI tools (actually those are where I do drop to plain http). I'm sure this lcl.host product smooths this process considerably, but when it comes to local dev tools, I have an absolute requirement that they actually run locally and don't tether me to some cloud service, so I'll be sticking with traefik regardless for now.

Re: Lcl.host: fast, easy HTTPS in your local dev environment

#40

Post by afavour »

chuckadams wrote: post #38
hk1337 wrote: post #29

Earlier quoted context omitted.

I've always thought the need for local HTTPS was unnecessary for at least 90% of the projects and brought no real value other than making the developer "feel" better. localhost with HTTP should be sufficient for most things. It's when you start doing stuff like "app.localhost" like what was mentioned in the article which, despite it having "localhost" is not the same as http://localhost . Develop basic in local and d…

There are a number of APIs, such as geolocation, that only work over https. It's also very common to accidentally generate non-https urls for assets, which is a bug most people would rather catch in local dev and not production when the browser refuses to fetch them. I use traefik to serve my apps in dev, which generates self-signed certs by default if you don't hook it up to ACME. Slightly more cumbersome because it…

> There are a number of APIs, such as geolocation, that only work over https

And localhost

https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

Post reply on HN