That's why this Category #2 stuff is so important. People can agree without much controversy what "best practice" is for the Category #1 stuff, but at the next level it's just blog posts and discussion thread comments passionately arguing opposite statements.
I'm curious... if not JWT, then how would you approach the problem of authenticated sessions without server-side state? (assuming you aren't rejecting the overall premise entirely)
If you track authentication with a server-side session, then you have to either:
(1) Setup a backing store for your session state (e.g. Redis, relational database, proprietary app server solution, etc). Share the backing store across all instance nodes in your server-side cluster. Tune the inevitable performance issues and point-of-failure risks, and expect the worst if you're using a proprietary thing (they're all terrible).
(2) Use a hardware solution. Have the load balancer always route a given client's requests to the same server-side instance. Deal with failover scenarios when that instance goes down, have to drain traffic every time you want to do a deployment, etc.
JWT's ugly, but no uglier than either of those! Always on the lookout for other recipes...
'lvh and I are working on a piece about this for our clients, so I want to be careful not to write a crappy version of it in an HN comment first. But I think you'll find something close to a consensus on JWT/JWS/JWE/JWK among crypto engineers of our ilk.
I guess I'd close by saying: if you were writing a Rails app, it's almost certainly the case that you'd be better off just using ActiveSupport::MessageEncryptor to create an encrypted token than you would be building a shambolic equivalent of MessageEncryptor in JWT.
We're pretty heavily invested with using JWT wrapped inside OpenID Connect, and given you garner a lot of respect on such topics, I'd really be appreciate if you cited a source or gave us a reason. Anything would be better rather than just appealing to a vague consensus.
This thread, though, is about Go web applications. So I guess apropos this thread, I'd just say we probably don't need an example of how to use JWTs in Go. But session management, yes!
I never said it would, I was simply stating my interest in your opinion on the topic. It seems a shame that you don't seem to be willing to expand though.
What you recommend then instead of JWT in a non-Rails environment?
token = data:expiry:hmac(key, data+expiry) is super simple in most languages, is robust, and nacl provides useful helpers for doing this as well.
There's a sort of intuitive insecurity quotient for things that goes something like C/W_s where C is complexity and W_s is the number of people in the world who would be screwed if something was totally broken.
Encrypted session cookies have, as a design, relatively modest C and very, very high W_s.
JWT has extraordinarily high C and, at present, modest W_s (relative to session cookies).
(They also have a bunch of design flaws that amplify their complexity).
This has been discussed on HN before and I remember talk about using "fancy" stuff like Bloom filters but as far as I know, no library offers anything for this out of the box and this is not something you want to roll yourself.
Which is fine and well. But how does that take revocation into account?
You can store a token on the client side, in ANY format. The problem remains that you're either storing some server-side state about that token, or you aren't. If you are, then you're not really using client-side sessions. If you aren't, then you still don't have a good way to revoke. Because you can't really control the client-side after you've issued a token, and you can't revoke it from the server-side without state.
I'm sure there are good arguments to be made against the use of JWT. But their simply aren't any to be found in this thread, and no alternative client-side proposal that solves the revocation problem.
Developers would like there to be one. Unfortunately, they've chosen a terrible standard --- just really, really bad --- to run with. You are better off doing something by hand than using JWT. If you're at all familiar with my ouvre on HN: that's how bad JWT is. I think you might seriously be better off DIY.
FWIW, gophish is a very clean app built using Gorilla packages that implements these patterns in a comprehensible way and I found it very helpful as I was implementing things.
Once you cover (1) most of the others fall into line. There is little reason to use context values outside of MW from my experience.
Re (3) - can you provide a link or example of what you mean?
(5) - again, can you elaborate? Are you referring to error types? Or just how the errors are rendered?
I ask all these questions because I write a lot about Go and I am interested in trying to make examples of these available, but I want to understand what you are asking for first.
The end of your article advocates a little bit for just accepting code reuse, and the getter/setter/subfunction thing comes perilously close to GoF Java style for my taste. Further: I have seen, routinely, on pretty much every project I've worked on, serious production faults from errors and omissions in duplicated code. I'm not sure I've seen equivalently serious production faults (really: any faults) in overuse of things like "context".
Full stack website that reuses template parts with live data, manages sessions and logins, images, JavaScript and CSS...not so much.
Authentication - there are a few good examples out there, I think gorilla secure cookie is good, CSRF protection too.
Authorisation - had to write my own version of the ruby lib cancan, am now happy with the solution
Images - stdlib is pretty good but it'd be nice if it handled resizing images and exif orientation tags.
Javascript and CSS - there are some ports of minifiers in go so an asset pipeline is pretty easy.
ORM - I use a query builder and use the map columns->fields in code, not keen on the orms using reflection and/or struct tags to do so. This doesn't have to be complex though.
Migrations - there are a few libraries out there now, so this isn't bad, I prefer sql migrations.
Templates - love the context-sensitive escaping, would be nice if it handled layout/partial but this is doable with some tweaks.
Forms - generation of views with text/template is pretty handy to handle things like CRUD forms for models.
This is where frameworks are useful - they present best-practices for the above details and more that you have to handle in a full-scale webapp.
I think those are the areas I'd like to see more tutorials on for beginners coming to Go, but there are solutions out there nowadays (far more than even a few years ago).Most of the things you mention are not in the std library so I guess people feel a little lost when they first arrive in Go land, but there are a few libraries out there like gorilla which cover most of this stuff or you can write your own, and once you have it's a really pleasant language to write traditional server-side apps with.
So with the above caveats I'm really happy with it for full stack web development.
Just as an example, my go to test for most programming languages is to rebuild my personal site with it (http://brightball.com/). Just provides me with a good exercise in running through a simple project that I've done in multiple languages and provides a good basis for comparison without getting too fancy.
If you'll look at the page layout, you'll see the main content area with a list of articles, some sidebar elements that are loaded from the database and a list of primary tags in the footer (also pulled from the database).
The biggest pain point was the reusable elements (sidebar and footer) with the template system. In most other template systems it's pretty trivial to write parts that have code attached to them and tell a layout to call those pieces with some arguments. With Go, that was a bit of a pain requiring all of the data that that would appear on the page to be retrieved before starting the rendering process. That led to a lot of repetition to pull in that data on every path to the layout.
So the layout/partial system would be my biggest pain point. My first instinct was to go and reach for a framework but so much stuff that I read on Go boards gave the impression that the community seemed to have a very negative impression there.
Additionally, there wasn't a clear winner among frameworks which made me hesitate. That's a problem you see in languages that have so much stuff for the web built in like PHP and Javascript. It becomes so easy to do-it-yourself on the framework front that there are a million different flavors and no clear path.
With Ruby, Python, Elixir, Groovy, etc there are clear and dominant frameworks for the language. If you learn this language, you should know framework "X". When there isn't that clear winner, it's hard to justify investing in developing around it.
To try to get around that issue and the sense that with Go you were supposed to sort of assemble your own parts, not commit to a framework, etc I tried https://github.com/runemadsen/ok-go since it's basically a framework of assembled and replaceable parts.
After a while I just gave up on it and started looking at porting to Hugo before I found out about Elixir and gave it a shot. Ultimately, that was exactly what I was looking for (http://brightball.com/articles/insanity-with-elixir-phoenix-...).
Most of the issues I describe are non-issues if Go is backing a React/Angular app instead. I just found it to be a huge pain for entirely server side applications.
Thanks, this is what I'm talking about too (server-side web apps), I've found it a good fit, but do understand the initial difficulties with html/template - it is not very user friendly and was not designed for the sort of layout/partial arrangement that almost every web framework uses, however it can be used in that way with a little tweaking. That data has to be retrieved somehow though for the sidebar say, so I don't mind having to pass it in explicitly - it at least makes all the work being done explicit.
Agreed on the frameworks issue, frankly I find the hostility to frameworks on places like /r/golang tiresome and cultish - there is the kernel of a good idea in rejecting frameworks (they can after all straightjacket your code and invert control), but there can be many benefits to them and they provide essential pointers for those new to the language. I think for Go to grow it does need people to start to coalesce around solutions so that beginners don't have to reinvent rails again for every app or (worse IMO) start using JS for frontend and Go for backend - then you have two problems (or 400,000 if you use npm). I prefer server-side only and am happy with Go for that.
Elixir is on my list to check out, thanks for the link.
{{ select "Order" "form_name" .value .options }}
1. Examples of using context values to pass things selectively to handlers.
2. An arbitrary trivial middleware example, like a specialized request logger, just to demonstrate Go middleware.
3. A Rails/Django-style session token done in the same middleware style.
4. Giving requests a notion of "current user".
5. Simplified user-visible vs. developer-visible error handling.
It's too much to ask for ORM-style database query examples, I know, but that too would be nice.