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:
Can we use cookies for sending the custom headers from client and retrieve them in server side?
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
Assuming you're talking about a webSocket connection from a browser, here are your traditional choices for sending additional "header-like" information.
You can encode them as a query parameters on the initial URL which might be fine for everything except auth-token.
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.
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.
Related
Wondering about my security approach.
We have a web server with some kind of backend, and a JS frontend.
Users have to login through the frontend, with regular GET/POST requests, they get a HTTP-only session cookie set as well as a particular "wstoken" string that is available to the JS (by setting it with <script>wstoken = 'xxx';</script>
The frontend then opens a WS connection to the API server and sends an authentication request with the wstoken. If the wstoken matches what we have for the user in the DB, we accept the authentication request and consider that WS connection to be authed to that user.
I'm wondering if I'm doing it right.
We have a Google http(S) LB in front of a Google Compute VM, and we are routing a subdomain to the backend which exposes only a wss endpoint. I couldn't find any example for javascript code how to use Authentication with Google IAP and OIDC Tokens.
Does Google IAP support query parameters for the authentication ?
I found this entry:
Bearer authentication for websocket
Thanks for any advice
There is no method in the JavaScript WebSockets API to customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that are sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible. One way to attain this is using a “ticket”-based authentication system.
When the client-side code decides to open a WebSocket, it contacts
the HTTP server to obtain an authorization “ticket”.
The server generates the ticket. It typically contains some sort of
user/account ID, the IP of the client requesting the ticket, a
timestamp, and any other sort of internal record keeping you might
need.
The server stores this ticket (i.e. in a database or cache), and
returns it to the client.
The client opens the WebSocket connection, and sends along this
“ticket” as part of an initial handshake.
The server can then compare this ticket, check source IPs, verify
that the ticket hasn’t been re-used and hasn’t expired, and do any
other sort of permission checking. If all goes well, the WebSocket
connection is now verified.
Refer to the link for websocket security and related stack posts HTTP headers in websockets client API and Websocket authentication.
I have some access to socks5 server (host, port, username and password). I need to be authorized and then make several requests to different servers by TCP via this socks5 proxy. How I can make it with node.js?
I found library socks-client and it is ok, but I have to be authorized for each request to remote server (by using method 'connect'). How can I solve my problem?
That's the nature of the SOCKS protocol. You connect, authenticate, and then if successful normal data is transferred back and forth on the same connection. There is no way to re-use a connection, so you have to repeat the process for every new connection you want to make.
I can prevent other web sites (e.g. example.com) access and use my server resources via WebSocket. I mean they cannot access the server by pointing to something like "ws://47.80.151.189:1234" and use its resources (bandwidth, memory) or receive data sent from it. It’s a node.js server.
However, my local computer can still receive data sent from that WebSocket url. It can still receive data even in this file location: file:///D:/test.html
I don't want the data exposes to anyone. So how can I prevent this and thank you.
You can restrict browsers connecting by checking the origin HTTP header.
When a JavaScript script running in a browser opens a WebSocket connection to some server, it will set the origin header to the URL (well, host) of the original HTML that contained the JavaScript that opens the WebSocket.
Note that non-browser clients are not required to provide an origin header and/or can fake to anything.
You can also restrict of course based on source IP of the connecting client. Or you can require some kind of authentication.
I have a browser based app that needs to communicate with another service running on the client machine via a socket connection from the browser using JavaScript.
I need to post and parse XML back and forth on the socket.
I am unable to go down the flash path as the cross domain security is a barrier, ie the service running on the socket is not able to be modified to support Flash's crossdomain security.
What are my options for a pure JS based solution?
You've got two major problems here:
It's difficult in javascript to access non HTTP resources,
It's difficult in javascript to access resources not loaded from the same server.
There are exceptions to both of these, but the conjunction of exceptions available might not exactly match with what you need. Here are some possibilities:
Some sort of proxy on your own server that connects back to the machine with the XML service on behalf of your web app.
If you can control the client machine somewhat you can run a server on it that can embed the XML in a JSONP formatted http response, you can access by adding simple script tags, and send messages the other way by using a script tag to request a url with your data encoded into it.
If when you say 'socket' you're referring to an HTTP connection, then there are a number of options, one is to add a Access-Control-Allow-Origin header to the HTTP, then you can do gets and posts using normal XMLHttpRequests in recent browsers.
Javascript will not allow you to create a socket connection to the client. It would violate the same origin policy. If you could somehow save an applet/swf to the local machine you could serve it up as file:/// and it could communicate to localhost (maybe! not tested).
Maybe creating a proxy to go in front of this unmodifiable socket server could open up some options for you. You could then use something like flash, or you could just not use sockets.
Your options for socket based interaction is limited to plugins that support such live functionality. The options generally break down as follows Flash, Java and Silverlight. All of which aside from Java, if I recall correctly, will have similar policy requirements.
If you control your own server, you could create a socket service to proxy the request to the final destination. Or, depending on the interaction, you can use standard Ajax-style requests and have the socket interaction on your server-side code. If you don't need a persistent connection, having the socket interaction via the server is your best bet.