I am connecting to a remote browser instance as follows:
const browser = await puppeteer.connect({ browserWSEndpoint: webSocket });
At the remote node, I am maintaining a pool of browsers, so the above could be attaching to any one of those. The webSocket above isn't for a specific browser from the pool... it is a fixed websocket address for the remote node, and at the remote node I am proxying the request to one of the browsers in the pool.
Mainly for debugging/tracing purposes, is there any way to assign an ID to each browser instance at the remote node, which can be read from the browser (above) at the local node, so that I can see (at the local node) which one of the remote browsers has been assigned?
I thought about setting the User-Agent of the browser (when it is created at the remote node, which would be readable back at the local node), but it seems that this can only be set at the page level, not browser level.
Related
I am doing a code based load balancing i.e. on first request to the main server, it returns an address, to which the browser will open a persistent conncection using (wss) websocket. But, due to compatability with my mobile app, i'm returning a public DNS of aws instance, Ex: ec2-35-154-101-63.ap-south-1.compute.amazonaws.com which works fine in the mobile app. The browser however is refusing the connection because the address of websocket is not matching the parent domain. Are there any options to fix this other than using a Wesocket address from the same domain.
Edit: I had no choice rather than return a subdomain address for the websocket connection.
You are connecting to a URL that does not match the name in the SSL certificate.
You have two choices, either map the domain name to the instance or (not recommended) issue a certificate that matches the URL that you are using (ec2-35-154-101-63.ap-south-1.compute.amazonaws.com)
The correct approach is to specify the A address (IP address) in your DNS server for the EC2 instance so that requests for your_domain_name resolve correctly and then USE that URL and not the EC2 instance DNS name. You cannot specify the AWS URL for https as the SSL certificate was not issued to that identity.
I built the server into Java,The server sends (image)data to the web browser through a web socket.So far it works fine.
and I wand that The web browser send data from the server to another web browser (client) using webRTC, So I looked for the webrtc...
I noticed that there are occasions when you need to use webSocket with webRTC
What is the role of websocket in webRTC?
In order to establish a WebRTC connection between two browsers, these browsers will have to negotiate a connection first. To negotiate a connection they need to be able to talk to each other. But they cannot talk to each other because they have not established a connection yet.
That's where a signalling server comes in. That's a server that both peers are already connected to and which can relay messages between them until they have established a connection. Using a websocket connection for this purpose is the most useful way, since it's a (soft) realtime bi-direction communication channel, exactly what you want when relaying messages as quickly as possible.
It doesn't have to be a websocket though; AJAX and/or long-polling will do too, but they have more overhead and are slower, which means it will take longer to negotiate the WebRTC connection.
I am building an application that is using websockets. I am only going to allow authenticated users to open a websocket connection with the server after they have logged in and have been granted a session id.
Once I have opened a websocket connection with an authenticated user, the current "page" then holds the details of the open websocket connection. At this point, is this connection relatively safe? Or should I really be checking some token on every message within my own application level protocol that comes in over the websocket?
Are there any known cross-site forgery type security issues? Where someone could coop an open websocket by getting the authenticated user to execute some javascript in some manner - resulting in the ability to exploit the open websocket connection?
1) The connection is safe, when you make it safe on the server side. So you have to send a session ID via WebSockets, verify on the server side that it is correct and mark the connection as valid. Authentication is more difficult with HTTP, because HTTP is stateless ( unlike raw TCP ). Of course it is still possible to hijack TCP connection, but it's not that easy ( see for example this article ) and if it happens, then nothing ( except for TLS ) can help you.
2) Well, if you wrap your WebSocket connection with an anonymous function like that:
(function() {
var ws = new WebSocket("ws://localhost:1000");
// some other stuff
})();
then no external JavaScript will be able to access it, so you don't have to worry about that.
I am trying to understand the purpose of websocket multiplexing extension, the main purpose what the document states is to use a single same origin physical websocket connection to the server while each browser tab uses a logical connection multiplexed on top of physical connection. I see another alternative using which we can accomplish this behavior today, the approach is to launch a shared web worker which opens the websocket connection and let each browser tab send and receive message to/from this worker. i have not tried this yet and i wonder will this work at all.
Your question reflects a misunderstanding of the problem the WebSocket Multiplexing Extension is trying to solve.
The base WebSocket spec (RFC 6455) defines a protocol for bi-directional exchange of data over TCP/IP. A WebSocket starts as a normal HTTP request / response. In this exchange, the client and server negotiate to switch to the WebSocket protocol. After the switch, the client and server exchange data frames over the TCP/IP connection. This creates a bi-directional data stream between client and server.
A drawback of the base protocol is that it supports only a single stream of data flowing in each direction. The multiplexing extension augments the base protocol, by allowing the client and server to create multiple "channels" over the same TCP/IP connection.
So the purpose of the multiplexing extension is to allow multiple WebSocket channels to run over the same TCP/IP connection. That's all.
Having multiple browser tabs (or web workers) share a single TCP/IP connection is just an example of how multiplexed websockets might be used. In standards terminology, it's just "informative" (descriptive), not "normative" (a required part of the spec).
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.