←back to thread

Go-Safeweb

(github.com)
188 points jcbhmr | 2 comments | | HN request time: 0s | source
Show context
pushupentry1219 ◴[] No.42133267[source]
Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.
replies(6): >>42133422 #>>42133588 #>>42133628 #>>42134049 #>>42134283 #>>42135953 #
bayindirh ◴[] No.42133422[source]
While I understand the sentiment, this makes bare installations too hard.

A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.

That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastructure to run that small thing.

replies(4): >>42133440 #>>42133543 #>>42133601 #>>42133665 #
NhanH ◴[] No.42133440[source]
Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those
replies(3): >>42133468 #>>42133705 #>>42133868 #
1. bayindirh ◴[] No.42133705[source]
I mean, tons of "old-school" services handle these things fine for the last two decades, at least. It can't be that hard. It's just a TLS library, and some files in a specific format at the end of the day.
replies(1): >>42133819 #
2. redundantly ◴[] No.42133819[source]
In my experience, most people have an extremely hard time wrapping their minds around how to configure TLS/HTTPS services and fail completely at understanding how it works.