To this day I still dont know why WebSockets and SSE dont support sending headers on the initial request, such as Authorization. Leaving authentication on realtime services entirely up to whoever is implementing the service.
I may be wrong here and the spec suggests a good way to do it, but i've seen so many different approaches that at this point might as well say there's none.
The EventSource API (the browser "client API" for Server-Sent Events) leaves a lot to be desired. While I am a maintainer of the most used EventSource polyfill[1], I've recently started a new project that aims to be a modern take on what an EventSource client could be: https://github.com/rexxars/eventsource-client.
Beyond handling the custom headers aspect, it also supports any request method (POST, PATCH..), allows you to include a request body, allows subscribing to any named event (the EventSource `onmessage` vs `on('named event')` is very confusing), as well as setting an initial last event ID (which can be helpful when restoring state after a reload or similar). And you can use it as an async iterator.
I love the simplicity of Server-Sent Events, but the `EventSource` API seem to me like a rushed implementation that just kinda stuck around.
Nice work! This addresses many of the issues I've had with SSE.
Another problem we've never worked out the solution to, is how to send a termination - signalling "there are no more events coming". We always end up having to roll our own, though it felt like something that should've been handled at the protocol layer.
I do login the bog standard way with a regular old http request and the server responds with setting an http only cookie. Then I reconnect the websocket, which will then provide the cookie to the server on reconnect.
The browser EventSource constructor does not have options to pass in your own headers. You can pass an option to have it use the cookies for the domain you’re using. There are libraries that allow you to pass in additional HTTP options, but they essentially reimplement the built-in EventSource object in order to do so. Not terribly difficult, fairly simple spec.
Well, that constructor by default sends all the headers you have for your own domain and auth you are entitled to. This is how all other APIs in browsers work due to security and privacy concerns.
If you call to other domains, then this problem is no different to what we had with CORS years ago.
Oooh boy you touched a pet peeve. I mean who needs authentication on the modern Web right? /s
The even more irritating thing is that there is nothing preventing this, and every server I've tried supports it. It's only the browser WebSocket API that was designed without this. Cookies are the only thing browsers will deign to send in the initial request.
I may be wrong here and the spec suggests a good way to do it, but i've seen so many different approaches that at this point might as well say there's none.