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?
Lcl.host: fast, easy HTTPS in your local dev environment
21–30 of 101 posts
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#22We built something similar for docker-compose based projects: https://gitlab.com/hukudo/ingress
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#23Were some bugs that show only in the https version of the app?
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#24I've used this service in the past, http://local-ip.co/ which provides downloadable private key and certs and they run a dns service that resolves to any IP address.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#25Earlier quoted context omitted.
When I first announced Caddy, our website downloaded everything as .gz due to high traffic load -- a lesson I learned very quickly and a mistake I never made again. This probably falls in the same boat. :)
Sorry, maybe it's too early in the day but I don't get what the lesson was. Could you explain?
(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?
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#26Earlier quoted context omitted.
Sorry, maybe it's too early in the day but I don't get what the lesson was. Could you explain?
(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?
Yeah, exactly. A lot goes into shipping, and sometimes things like this can be overlooked, especially on a small team that needs to deliver broad platform support right out of the gate.
There are some bugs that are just hard to find until they're out there.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#27Why 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?
We install the CA certificates into the trust stores so that the certificates are trusted by your browsers and clients, otherwise they will (rightfully!) get connection errors. We also set the CAA records for all lcl.host subdomains to anchor.dev, so no public CA will issue certificates for *.lcl.host. The only valid certs for lcl.host subdomains you will encounter are for your account's CAs. If we gave everyone a cert+key for *.lcl.host, besides the security concerns, we'd have to keep redistributing them every ~45 days, but with lcl.host you can setup ACME to automatically renew certs before they expire.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#28Earlier quoted context omitted.
Sorry, maybe it's too early in the day but I don't get what the lesson was. Could you explain?
(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.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#29It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long ru…
> 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 do all the hostname + https on actual server where you can easily do something like letsencrypt route DNS to it.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#30Earlier 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.
To clarify, every page load (.html file) was downloaded as a .gz file instead of being served as an HTML file and displayed as a web page in the browser.