Any reason why these tools usually don't support windows ? Is it harder on Windows ?
Lcl.host: fast, easy HTTPS in your local dev environment
71–80 of 101 posts
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#72I was working on something similar with https://github.com/cpendery/wock. Never finished it up, but this looks promising
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#73I don't see OrbStack mentioned here much, but it's completely replaced Docker Desktop for me. Aside from having a better UI, faster and uses less battery, it also gives local https with custom domains for free [0]. [0] https://docs.orbstack.dev/features/https
OrbStack was mentioned often with all the Docker Desktop / Docker open-source organization drama in the last year or two. But that was when it was free for all, now it's paid for commercial licenses which is less attractive for organizations to switch over. We're all on Colima. But the local https feature is a nice little feature for sure.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#74Earlier quoted context omitted.
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.
We just released a fix for the version error, this will be the last one you see, we promise!
How about being able to disable the check entirely? I really dislike tools phoning home unless asked.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#75Earlier 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…
I figure you could create the CA, have your browser trust it, create and sign your localhost cert, and then nuke the CA private key so no other carts may be signed.
It'd be annoying if you need to make a new localhost certificate, but totally manageable.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#76It 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…
You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert
You don't even need that. See https://simpatico.io/devops/deploy.sh#generateSelfSignedCert() and also #generateRootCA()
Then point your server to the output files. If you want, you can also modify `/etc/hosts` to point a "production name" to localhost (something I actually don't do and never wrote a script for). Far fewer moving parts than the OP. (parts of Simpatico uses subtle.crypto and so requires https to run even locally)
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#77It 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…
[dead]
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#78Earlier quoted context omitted.
That's an absurd tactic I've not seen since last time I used Firefox.
you're completely free to run firefox from 5 years ago and it will not refuse to run.
No, you are not.
Mozilla bricked SSL certificates that are mandatory for everything, including Browser Extensions.
There is a flag for about:config to unbrick it. Problem is though, that this lasts less than a second because of the remote settings service running in a loop. If you block that services domain with a host firewall (like opensnitch), Firefox will do an endless for loop using 100% CPU load trying to request the shavar and other services domains.
So, effectively, you cannot run an old Firefox version, and especially not a version that uses the old bundled mozilla certificate (which is all provided download variants).
That's what the previous commenter was (likely) referring to.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#79I 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…
This would be perfect if combined with Traefik's method of config via docker tags.
The Caddy Docker Proxy Module enables Caddy to act as reverse proxy for docker containers via labels: https://github.com/lucaslorentz/caddy-docker-proxy
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#80Warning: 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.
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. :)
When we first release cdnjs.com we used tools to check if the DNS had fully propagated... but it hadn't. The shame of a cdn being down in several places across the globe.