Using HTTP Basic Auth (with Logout!) in a Go Application

HTTP Basic Auth (Wikipedia) is a thing that is actually still quite useful despite its neglect in modern web standards. By neglect, I mean that it hasn't been updated since its introduction in RFC7617 and as such the logout mechanism hasn't been improved to take into account modern browsers' tendency to aggressively cache session data within the HTTP headers, which is where the login state is stored. However, with some tricks it still can reliably be used in modern browsers. But some Javascript is required, sorry :(

First, a note: don't even consider using HTTP basic auth in your public-facing page unless you have it served behind an HTTPS reverse proxy! The username and password, sent to and fro from client to server in the HTTP headers, is in plaintext by default, and only HTTPS with TLS will guarantee that the credentials in those HTTP headers are encrypted.

Given that caveat, here is a complete minimal example of using HTTP basic auth to gate access to a Go web app.

Go Playground Example <-- this won't work in the Playground -- copy and build locally

FAQ

Q: Go's http lib supports TLS to serve out endpoints. Why didn't you just do that instead of serving out an HTTP app behind a reverse proxy?

A: HTTP basic auth seems to be mutually exclusive with direct use of the HTTPS protocol (see my comment at start of this post about the 'basic auth' mechanism being neglected...). Perhaps I missed something. Let me know if I'm wrong, and how to do it securely without an HTTPS reverse proxy! Thanks.

Q: How do I support multiple users/roles using the example you give?

A: No idea. I think it could be done, with auxiliary logic to track separate session users/passwords, but this is left as an exercise for the reader. [Meaning, like all my college profs ... I forget/I can't be arsed to work it out right now.]

-R.

bacillμs - a simple build automation server written in Go

Most non-trivial software projects that do rapid releases use a build automation server. One of the most popular solutions for this is Jenkins. There are many others.

While Jenkins is easy to install and use in my experience, I wanted to learn some others to broaden my expertise, like Concourse https://concourse-ci.org/ or buildbot https://github.com/buildbot. The former turned out to be hellish to install and I burned a few evenings hitting many head-scratching dead-ends in the start up config; forums were filled with users asking the dev team for updated installation instructions, met with brusk dismissals if one wanted to use it outside of the dev-blessed containers (ie., use our black box, never mind how it really works). The latter, while easier to get up and running in a 'hello world' configuration, seemed difficult to configure further into a real-world setup. It seemed to me that these things, in general, are overly complicated.

So, in a fit of insanity I wrote my own simple build automation server in Go. No containers, java VM, or dependencies.. Use whatever scripting language you want. Total line count is under 1k.

Of course, it's nowhere near production quality, and probably violates every go coding standard there is, but it does the essential things one might expect: responding to git triggers or webhooks from web-based systems like gogs.io or gitlab, a web dashboard, viewing of running and completed jobs and their artifacts. Jobs may be scheduled (externally via cron), or launched manually from the dashboard. Jobs can be parameterized, with a simple but powerful form notation to allow int, string, and boolean job parameters. Build artifacts are archived and browseable from the dashboard. There's even a simple way to display stages of a job's run in the live view, aka a simple 'pipeline' status.

https://gogs.blitter.com/Russtopia/bacillus/src/master/README.md

Suggestions welcome.