4

I know there are no standard JS WebSocket APIs for the same. My main aim is to send the info like resourceId, routingInfo, auth-token, protocol etc. from JS web-socketclient to the server.

I could think of below few approaches. Kindly share the thoughts if my approach is fine or is there any other better approach:

  1. Can we use cookies for sending the custom headers from client and retrieve them in server side?

  2. Can we use web-storage API for storing them in the browser and retrieve them on server side?

PS: I am using a Java based server

Improve this question

1 Answer 1

Reset to default
5

Assuming you're talking about a webSocket connection from a browser, here are your traditional choices for sending additional "header-like" information.

  1. You can encode them as a query parameters on the initial URL which might be fine for everything except auth-token.
  2. If the origin you are connecting the webSocket connection is the same as the origin of your web page, then you can put the parameters into cookies and those cookies will be sent with the original webSocket connection request where the server can retrieve them upon the connection request.
  3. You can make a "conditional" webSocket connection to the server and then send credentials in subsequent webSocket messages. You'd have to implement safety for that on your server so that the "conditionally" connected webSocket was not allowed to do anything else except authenticate itself and probably timeout the connection if appropriate credentials do not arrive shortly.

As it sounds like you may already know, the browser interface to webSockets does not allow custom headers on the initial HTTP request that starts the webSocket connection. Those custom headers are possible from some other kind of client - it's just that the browser interface to a webSocket connection does not have that feature.

Can we use web-storage API for storing them in the browser and retrieve them?

The Javascript in your web page can use the web-storage API to store data in the browser and that data can be retrieved later from another script in a page from the same origin. That data is not available to the server, it is only available within the client.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Thanks @jfriend00 for the prompt reply. I don't have to send them as query parameters due to security issues. And one more clarification required, if we set the data in web-storage API, can we retrieve them in server side also?
@rahul - No. web-storage API is client-side storage only. You can only access it from the client (it's stored by the browser in the local computer's file system).
@rahul - FYI, if you're using SSL to protect your webSocket connection, then the URL itself (include query parameters) are not visible to anyone other than the receiving server.
Another option: 4. Have a GET api that returns a temporary, 1-use only websocket URL. That GET api can take whatever APIs you want, then the client connects to the temporary (say, 30 seconds) one-shot URL. A bit like an auth token, but it's completely safe to include in the URL and have it logged, since once it's been logged, it's useless.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.