For those who are new here, I'm building an open source tabletop roleplaying assistant. Right now, I'm working on the real time aspect of it as I need that for another project.
From a purely MVP point of view, it's not strictly the best thing to work on, but as I need it for something else, I'm making an exception...
So far, we've created a server that is capable of streaming to multiple clients over server sent events(SSE). I didn't do much over the weekend because the weather was nice, and it's healthy to take breaks.
I haven't made a huge amount of progress today, but I'm just going to talk through the issue that I have. I need to spend some more time thinking about it.
The issue
Go allows easy composition of HTTP handlers via middleware, and I want to ensure that the library is reasonably pluggable. In an ideal world, the handlers should be completely separated from any authentication logic.
However, SSE only allow you to do a GET requests, which means the only way of authentication has to be via a cookie, or a query string. The subscription endpoint also needs to know which client is actually asking for that subscription, and the streaming handler needs to know which client to send the data to.
For the streaming handler, there's a few solutions, including a short lived token that gets generated on a handshake endpoint as a signed session cookie.
For the subscription handler, it's easy enough to create some authentication, but the userID (or equivalent) does need to be passed in to the subscription adapter.
What I'm leaning towards right now is a configurable authentication function that's passed into each handler, but that's another layer of configuration on top of the library.
I'll have a think about it and see if I get any closer tomorrow.
Top comments (0)