Go-Safeweb
github.com
Go-Safeweb
1–10 of 78 posts
Re: Go-Safeweb
#2[flagged]
Re: Go-Safeweb
#3[flagged]
They should put it on all of their officially supported ones too!
Re: Go-Safeweb
#4[flagged]
It's an open-source library (or collection of libraries) for Go HTTP servers. Apache license, so it does not matter if Google supports it or not.
Re: Go-Safeweb
#5This is basically the helmet of go?
Re: Go-Safeweb
#6Not 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.
Re: Go-Safeweb
#7What does this mean?
> NG1: Safe API Completeness > Creating safe APIs for all the corner cases might result in a bloated codebased. Our experience shows that this isn’t necessary.
To me "Safe API" means it's hard to use the API incorrectly. I see lots of poorly designed APIs where it's easy to use the API incorrectly and then you don't know you've used it incorrectly until (1) the edge case you weren't aware of appears (2) you get pwnd by an exploit because you used it wrong.
Re: Go-Safeweb
#8This is basically the helmet of go?
I always thought that the "rubber" was a missed opportunity.
Re: Go-Safeweb
#9Not 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.
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.
Re: Go-Safeweb
#10Not 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.
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 infrastr…
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