Reputation: 8347
Context:
I'm developing a frontend app locally, calling APIs etc cross-domain (from localhost dev server to our server on another machine inside the local network). Since our local network is isolated, the backend server has CORS enabled which doesn't cause security problems; this is different in production (CORS is disabled).
We introduced WebSocket connections in our app and to secure it with authorization we added cookie check on handshake. (XHR requests are authorized via the Authorization header, cookies are not used there; but they actually can be used; WebSocket
interface only allows a limited set of headers and if we don't authorize via WS messages, cookies seem to be the only sane option; well, in fact I failed to find if Basic HTTP auth can be implemented without broswer standart prompt, and how to do that)
The problem:
while this actually works for production (when frontend and backend are on the same domain), and cookies are sent in the handshake request inside the Cookie
header (the code is trivial: I just set the cookie after getting the auth token), this doesn't work in development environment (localhost + backend on another domain): the Cookie
header is just absent in the handshake. The link above shows that XHR needs the withCredentials
option to try to pass cookie cross-domain; however, I haven't found a definitive answer whether there's something similar for WS or not. Here the author of a similar question just assumes that there's no such thing, but is it really so?
Upvotes: 6
Views: 2681
Reputation: 8347
On another project I've learned a "correct" way to handle this. Usually a higher level protocols are used with WS, like STOMP protocol. It has specific implementation for auth, so no cookies are needed actually; it has no drawbacks regarding CORS.
Upvotes: -1
Reputation: 31
Double check that the cookies that you're working with are set with SameSite=None and are secure
!
I was having the same issue, thinking that the cookies weren't being sent, because the chrome inspector doesn't show them on websocket connection request, but they seem to be once you mark them with same site none
and secure
.
Alternatively, to quickly check if that's the problem, you can disable the SameSite
requirement in chrome://flags/
Upvotes: 2