withCredentials missing for EventSource/SSE

[sidneywidmer]

Currently there are no event source options set: https://github.com/centrifugal/centrifuge-js/blob/master/src/transport_sse.ts#L43

This means that no cookies are sent to the connection/sse endpoint which make authentication hard. I currently use a workaround where I just pass in my own EventSource class. That works pretty well but feels a little awkward.

class CustomEventSource extends EventSource {
  constructor(url: string, options?: EventSourceInit) {
    super(url, {
      withCredentials: true,
    });
  }
}

const centrifuge = new Centrifuge(transports, {
  eventsource: CustomEventSource
});

Should we either send withCredentials to true or somehow respect the disableWithCredentials setting?

[FZambia]

Hello @sidneywidmer

I think this was originally done in this way to match a WebSocket behaviour in browsers, where Cookie is only sent for the same origin requests. Because bidirectional SSE and HTTP streaming are considered fallbacks for WebSocket in Centrifugal ecosystem.

By default, even without withCredentials option, EventSource sends cookie within requests to the same origin. Or am I wrong here? 🤔 Do you connect to a different origin?

Also, could you clarify – do you plan to use bidirectional SSE not as a fallback for WebSocket, but as the main transport?

[sidneywidmer]

No you are right, same domain should be no problem. But I'm currently using it on a different subdomain (also for local dev, different ports are considered a different domain i think).

I'm using it as a fallback, that is used surprisingly often especially in bigger companies where ws are blocked.

Hosting on same domain or using my "workaround" are viable options though.

Ps: i love what youve built, everything works smooth and the docs are superb! Adding SSE was done in an hour what could have been days :)

[FZambia]

Thanks for the info and kind words, appreciate!

So it's not a huge technical problem of course to add an option to include credentials to cross-origin requests in HTTP-based fallback transports. What I am worry about in that case though – this will make HTTP-based fallback transports different from the main WebSocket transport. The option will work for setups which do not replicate production state. Something like when your production works on the same origin principle, so all transports, including WebSocket, send Cookie, but in other environments WebSocket auth does not work due to different origin layout (staging differences, local development, as you mentioned). So potentially this may be a source of issues while testing – the main WebSocket transport is not properly checked.

What do you think? Do you already have production setup which works on the same origin, but only want cross-origin credentials for non-production environment? Isn't it a problem and you better replicate same-origin in non-prod environments too?

P.S. This is where Centrifugo's JWT based auth simplifies life a bit, as it does not deal with browser restrictions.

[sidneywidmer]

WebSocket Transport: send cookies to different origin by default
SSE Transport: don't send cookies to different origin by default

So by adding the "withCredentials" to the SSE it would be MORE similar to the WS no?

I'm not 100% sure if this is correct and a quick google search didnt yield any good results on how a websocket request handles this by default - but it looks like all cookies that match the domain/origin are sent by default (e.g domain=127.0.01, vs domain=127.0.0.1:8000)

But overall I say it's not worth the trouble to dig too deep into this and we can close the issue. :)

For future googlers your options are:

• use JWT
• use same domain
• use a custom CustomEventSource implementation

[FZambia]

WebSocket Transport: send cookies to different origin by default

Nope, cookies won't be sent to different origin with WebSocket – that's why the concern about different behaviour raised.

Yeah, let's not rush here and keep the issue open for some time – probably more opinions and use cases highlight sth.