How to set cookie header for webSocket javascript?

Question

I am trying to open a websocket to a server with kerberos authentication, error during handshake occurs (error code : 400) ; i saw it's not possible to send credentials through web socket and what i have to do is to set the username and password through web socket cookie and the server will read them. So how can i set cookies for web socket ? thank you,

Answer 1

You can set cookies for a webSocket connection the same way you set regular cookies, with document.cookie = xxxx . All webSocket connections start with an HTTP request (with an upgrade header on it) and the cookies for the domain you are connecting to will be sent with that initial HTTP request to open the webSocket.

So, as long as you are doing the webSocket connection to the same domain as your web page, then you can just set a cookie for that web page and it will be sent with the webSocket connection request. And, as with other cookies, you set a cookie using document.cookie as described here on MDN .

Answer 2

It depends on the browser. You may implement handling cookies if they arrive with the initial HTTP request to initiate a WebSocket connection, but if you can't require your users to, say, use Safari, which sends cookies with WebSocket open requests, and not Chrome, which does not, you'll probably have to implement a mechanism for the client to send in the session identifier in-band.

One simple way to achieve this is for the client code to send in the session identifier as the first message in response to the open event, and the server code to interpret the first incoming message's content as the session cookie, to set up the appropriate privilege context (or perhaps close the connection if the cookie is unknown or otherwise grants no privileges to its bearer).

Alternatively, if your WebSocket protocol has some sort of structured message infrastructure, you may define a specific message type for passing a session cookie to the server, as well as a matching response type for the server to let the client know what it thinks of the cookie.

It may be tempting to pass the session cookie in an URI parameter, as in ws://example.com/service?SESSION=123456 . This can be adequate in prototyping, but it is probably ill-advised in production, since session cookies should generally be treated as more sensitive than it is customary to treat the list of URIs requested from a web server. Passing session cookies in such a way can work in the short term, but may increase the risk of their accidental exposure via, say, careless analytics techniques. This concern could in some other context be alleviated by passing the sensitive identifier in the body of the request (for example, as a so-called POST parameter), but WebSocket open requests can not have a non-empty body.