Conversation

Notices

1. Aral Balkan (aral@mastodon.ar.al)'s status on Tuesday, 03-Jan-2023 23:48:32 JST Aral Balkan

   It’s mind-boggling to me the hoops we have to jump through to get https://localhost working for #web #development.

   Browsers should just show a pop-up: “Are you a web developer using https://localhost for testing? If so, we’ll treat it as trusted. If you don’t know what this means, answer No. [Yes, No]”

   And boom. If you answer yes, you can test with https://localhost without requiring mkcert, certutil, etc.

   (Until then, you can use https://codeberg.org/small-tech/auto-encrypt-localhost in your #NodeJS projects.)

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 01:10:43 JST Aral Balkan

     in reply to

     • Jim

     @odin Then just make sure your framework/platform handles all that automatically ;)

     https://codeberg.org/kitten/app

     (https://codeberg.org/small-tech/https)

   • Jim (odin@mastodon.world)'s status on Wednesday, 04-Jan-2023 01:10:44 JST Jim

     in reply to

     @aral but then we'd have a lot of web devs porting stuff into production without certs, etc, because "it worked just fine in dev"

   • Michael (michael@mstdn.thms.uk)'s status on Wednesday, 04-Jan-2023 01:12:44 JST Michael

     in reply to

     @aral This is still my favourite way of getting ssl on localhost:

     https://github.com/FiloSottile/mkcert

     Very straightforward, and it 'just works'

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 01:12:44 JST Aral Balkan

     in reply to

     • Michael

     @michael And, again, it shouldn’t be necessary :)

     My own Auto Encrypt Localhost (for Node.js) uses mkcert, which in turn, requires certutil, which requires the whole NSS tools from Mozilla. A very brittle and convoluted process for a common use case that could easily be handled by browsers.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 01:26:23 JST Aral Balkan

     in reply to

     • Raph J :verified:

     @RaphJ Thanks, Raph. I have my own module for automatically handling it all but the whole thing is brittle (mkcert, certutil/NSS).

     Might have to write a Node module from scratch without any external binary dependencies.

     But it could easily be handled in browsers.

   • Raph J :verified: (raphj@mamot.fr)'s status on Wednesday, 04-Jan-2023 01:26:24 JST Raph J :verified:

     in reply to

     @aral
     That's really anoying indeed !

     Have you tried "nginx-proxy-manager" ?

     https://nginxproxymanager.com/screenshots/

     I find it really useful to manage local development, together with dnsmask targeting localhost for *.dev

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 01:42:27 JST Aral Balkan

     in reply to

     • Digital Mark λ 📚 🕹 💾 🥃

     @mdhughes Hey Mark, that runs an http server at localhost:8000 not a server at https://localhost.

     I hate to link to this Google site, but here’s a good overview of the use case: https://web.dev/how-to-use-local-https/

   • Digital Mark λ 📚 🕹 💾 🥃 (mdhughes@appdot.net)'s status on Wednesday, 04-Jan-2023 01:42:28 JST Digital Mark λ 📚 🕹 💾 🥃

     in reply to

     @aral
     python3 -m http.server "$@" -b 0.0.0.0 8000

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 01:45:37 JST Aral Balkan

     in reply to

     • Alex, just zis guy, you know?

     @alexmorse To be fair, you’d still need a local web server. My point wasn’t about treating file:// URIs as if they’re being served by a server but for giving developers the option to have their https://localhost routes treated as trusted without having to mess with local development certificates and creating local certificate authorities and having them added to browsers.

   • Alex, just zis guy, you know? (alexmorse@mastodon.social)'s status on Wednesday, 04-Jan-2023 01:45:39 JST Alex, just zis guy, you know?

     in reply to

     @aral yeah it's silly. To the point where I got in the habit of just spinning up a dev server for projects

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 03:04:01 JST Aral Balkan

     in reply to

     • Fabrice Desré

     @fabrice Not for everything. https://web.dev/how-to-use-local-https/

   • Fabrice Desré (fabrice@fosstodon.org)'s status on Wednesday, 04-Jan-2023 03:04:02 JST Fabrice Desré

     in reply to

     @aral Why do you need https://localhost though? Browsers recognize http://xyz.localhost:port as a secure context, so if you properly use relative urls you can switch from such a local dev env to https://real-domain.org when in production with no hassle.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 03:09:50 JST Aral Balkan

     in reply to

     • Digital Mark λ 📚 🕹 💾 🥃

     @mdhughes Indeed, you can. And the moment we add that complexity to what I’m building, we’ve lost my target audience :)

   • Digital Mark λ 📚 🕹 💾 🥃 (mdhughes@appdot.net)'s status on Wednesday, 04-Jan-2023 03:09:52 JST Digital Mark λ 📚 🕹 💾 🥃

     in reply to

     @aral Sure, but generally you can develop at localhost:8000 and ship into an https container.

     You can also use Python's ssl.wrap_socket to specify https & PEM file, I just don't happen to have that script set up right now.

   • Aral Balkan (aral@mastodon.ar.al)'s status on Wednesday, 04-Jan-2023 04:11:49 JST Aral Balkan

     in reply to

     • Alex, just zis guy, you know?

     @alexmorse Oh, I think I misunderstood you. You meant you’d spin up a production server just for dev. (Otherwise, yes, that was the point I was trying to make too.) :)

   • Alex, just zis guy, you know? (alexmorse@mastodon.social)'s status on Wednesday, 04-Jan-2023 04:11:51 JST Alex, just zis guy, you know?

     in reply to

     @aral you need a local server just to hit http(s)://localhost