I'm picking my way through the dartiverse_search example from the welcome page in dart editor. I see that it uses a path route to decide whether to transform a request into a websocket:
// The client will connect using a WebSocket. Upgrade requests to '/ws' and
// forward them to 'handleWebSocket'.
router.serve('/ws')
.transform(new WebSocketTransformer())
.listen(handleWebSocket);
Is it possible to turn a request into a websocket without using a routing path, for example using a query string to the root url?
You can specify any condition for upgrading to a WebSocket connection. You can even upgrade any connection request to a WebSocket connection without specifying a condition like this:
WebSocketTransformer.upgrade(request).then((WebSocket websocket) {
websocket.listen((String text) {
// process sent data
});
websocket.add(JSON.encode("Hello"));
});
If the request is not a valid web socket upgrade request a HTTP response with status code 500 will be returned. Otherwise the returned future will complete with the [WebSocket] when the upgrade process is complete.
Related
I have a http route /checkout which initiates a workflow process in Zeebe. The checkout route will return 200 response straight-away to calling client. Now, workflow will run for a while. So to push the response back to client after completion, I have a /sse separate route for server-sent events. Here, I will store all the client connection in a global map.
My doubt is how do I find the exact client to send the response back through sse once?
Example: Client A listening to /sse and calls /checkout endpoint which will return 200. The /sse has to return the response to client A after completion.
Currently, I thought of using cookie to identify the client. Is there a better way?
If you are already using cookies in your app than that's the way to go since the very purpose of cookies is identifying the client, so if you already have that, you should use it.
But if you rely on another authentication mechanism (like JWT), what you could do is using the url as a query.
So in the client instead of
let eventSource = new EventSource("/sse");
Do
let eventSource = new EventSource("/sse?authorization=jwt_token");
In the backend, you would validate that token, extract the Client ID and hit that global map with it to retrieve the corresponding connection.
(PS: instead of a global map, you should use a proper store, like redis, or an embedded key/value store like bbolt)
I have a WebSocket server written which only handles upgrade requests which are GET requests. If a POST or any other kind of request with the required headers comes it is handled by a HTTP server.
In the specification it is not stated explicitly that the WebSocket upgrade request should be a GET request.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
Could this be a design decision where the server decides not to handle methods which are not GET requests?
From section 4.1 (Client Requirements) of the webSocket specification, it says this:
The method of the request MUST be GET, and the HTTP version MUST
be at least 1.1
And, then later in section 4.2.1 (Reading the Client's Opening Handshake) of the webSocket specification, it says this:
The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below (note that as
per [RFC2616], the order of the header fields is not important),
including but not limited to any violations of the ABNF grammar
specified for the components of the handshake, the server MUST stop
processing the client's handshake and return an HTTP response with an
appropriate error code (such as 400 Bad Request).
An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/
defined in Section 3 (or an absolute HTTP/HTTPS URI containing
the /resource name/).
So, there are multiple places where it says the http request must be a GET.
As for your specific questions:
Should WebSocket server only handle GET requests?
Yes, a webSocket connection will always start with a GET request, not a POST or any other method.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
As described in the above reference portion of the specfication, the server should respond with a status code like 400 Bad Request.
Could this be a design decision where the server decides not to handle methods which are not GET requests?
Yes.
From Using the JavaScript Client:
Notice the lack of a protocol prefix on the server URL. Do not add http:// or ws:// to the URL that you pass to the new dispatcher. WebSocketRails will choose the best available transport for you and prepend the correct prefix automatically.
I'm using WebSocketRails for the first time. I'm getting this error in the client:
WebSocket connection to 'ws://localhost:3000/websocket' failed: Connection closed before receiving a handshake response
If I navigate my browser to http://localhost:3000/websocket, I get the messages that I am expecting. If I navigate to the ws URL, I get ERR_DISALLOWED_URL_SCHEME. So it appears that the server is producing the messages, but the client is trying the wrong protocol.
How do I force the client to use the http protocol rather than ws, or force the server to broadcast it with ws rather than http?
Finally found the answer by digging into the source code. The second parameter of the constructor is called use_websockets and defaults to true. Setting it to false apparently forces it to use http instead of ws.
var dispatcher = new WebSocketRails('localhost:3000/websocket',false);
Currently, we are using a fairly standard setup with Node.js + Passport + AJAX as the webserver, Backbone on the client, and an app server exposing APIs for the back-end. The client makes AJAX request to Node, which does some housecleaning such as checking the session authentication, then passes the request along to the app server.
We are experimenting with replacing the AJAX portion between the client and Node with WebSockets. That part I have working fine. Previously we were using passport to check if the request was authenticated. With a standard Node route, the request and response is always included so this is a trivial task, but I'm not sure how to get it from the socket.
var server = http.createServer(app).listen(port);
var io = socketio.listen(server);
var namespaced = io.of('/socket/test');
namespaced.on('connection', function (socket) {
console.log('a user connected to /socket/test');
socket.on('fetch', function (args) {
// the client has sent a socket message which will functionally replace an AJAX request
// authenticate session here - how to get the request??
});
});
I'm trying to build a chat application based on sails.js. The url for messages from a specific chat looks like this:
/api/chat/:id/messages
When I request this url with XHR, it provides a session cookie and sails.js builds a session object. I can easily check user rights to read the messages from the specific chat.
However, I need to request this url with socket.io so that the client can subscribe to all future changes of the messages collection.
When I request this url with socket.io, no session cookie is set and the sails.js session is empty. So, I cannot check the user rights on the server-side.
I do understand that socket requests are not HTTP-requests. They don't provide any cookies on their own.
Is there any simple workaround?
I found a way to get the session object which was set while socket.io handshaking.
In your controller, you should do something like this:
myControllerAction: function(req, res) {
var session = req.session;
if (req.isSocket) {
var handshake = req.socket.manager.handshaken[req.socket.id];
if (handshake) {
session = handshake.session;
}
}
//session now contains proper session object
}
You can implement this in sails.js policy, and attach this policy to some controllers. But don't write you socket session into req.session! Otherwise, you'll get an error trying to respond to the client (original req.session is still used in some way). Instead, save it as req.socketSession or something like that.
please send a JSONP request from your application before sending a socket request,that will create a cookie and accepts socket requests.
You can do your initial login over the socket.post() instead of XHR, subsequent socket requests will be authorized.
alevkon,in the above mentioned method you have to implement the same in all the controllers,because you don't know which controller is accessed for the first time...but by sending just one jsonp request you can create a cookie between client and server,the same cookie is used until the next session.