I'm trying to "manipulate" an existing WebSocket connection of the browser.
For example: I visit the page example.com which creates a websocket connection with my browser.
Is there any way to access this connection and send data from javascript?
If you're trying to use your own Javascript to send data on a webSocket that the webpage's Javascript opened, then you will have to "hack" into the variables of the webpage to find how/where it stores the webSocket that it opened up. It would take some sleuthing through the site's Javascript to see how practical/possible that was. There is no "standard" way that a webSocket is stored in a page that allows you to just get it from there. You'd have to get it from the existing Javascript. If it's stored inside a closure, then it may not even be possible to get it from the console.
Or, you could just open your own webSocket to the page's server from the console and do whatever you wanted to do with your own webSocket using your own Javascript from there. You don't have to use the webSocket that the page opened as long as you can see from the Javascript in the page how it opens the webSocket and anything that might need to be sent in order to initialize the webSocket properly.
I would also suggest that you observe all applicable laws, licenses and terms of service.
Related
I'm using a website which uses Web Socket to send and get real time data. I trace it in Google Chorme and FF console and understand that after creating a web Socket use some methods in order to send and get data. Now I'm trying to imitate the procedure and manually do that! sending data which is exactly matched with the site format but I don't really know how can I make a connection and use the methods. when I traced the website I saw that some where in a code by using "this" access the connection so I couldn't find it out where the connection is created but I know all parameters of the created connection.
could anybody help me figure it out?
thanks in advance
There is not need for creating a new WebSocket connection, you can access the existing one by going to the devtools Memory tab, creating a snapshot:
Searching the snapshot for WebSocket:
Then saving the appropriate WebSocket object as a global variable (right click the object and select the Store as global variable option):
Have some way to keep the same socket.io connection on client side if user open a new page or refresh the page, maybe store the socket in session or it's impossible?
It's impossible. You cannot keep the same socket.io or webSocket client connection when the page is changed or refreshed. The browser simply does not do that. When a new page is loaded or the current page is refreshed, all resources from the previous page are closed and freed by the browser, including socket.io/webSocket connections.
So, your server has to expect a new socket.io connection from the newly loaded page. If you use cookies or a server-side session object, you can identify, on the server, when a connection is coming from a client that you have previously seen and the server can then act accordingly to realize that this is just a previous client reconnecting on a new page.
It seems now that WebWorker are a more widespread technology that it could be use to share websocket.
As explain in this article https://crossbario.com/blog/Websocket-Persistent-Connections/
Webworker are Javascript that is running outside the "thread of the page" and thus are not deleted on page change.
Note that it is running only in the same domain.
You can also look at Kanaka's answer here How to maintain a WebSockets connection between pages? (2012-2017 answer beware)
I use the javascript websocket to connect to the websocket server. I use python flask framework to navigate through webpages.
my project is as below:
the route "/" renders index.html page. In this page, I create a
websocket connection.
when I receive data from the server, I navigate to different route (for instance: "/page/1")
When i click on the href link on my index.html page, i see the websocket is being closed.
I googled out and implemented 2 methods of persistent storage.
LocalStorage
Shared Web Workers
Both of them were not of any use, since, the websockets are being closed when i click on the href link. From this I think that persistent storage of websocket instance is not a solution to my problem (please correct me if i am wrong). Please suggest me the right approach to tackle my problem. Thank you in advance.
I am using the latest version of google chrome (52.0.2743.82)
The WebSocket connection only persists as long as the page it was established for is open. Loading another page closes the WebSocket, so storing a reference to the object does not help (what it references no longer exists). You need to establish a new WebSocket connection after each page load.
(For an older look into how the problems here, see http://tavendo.com/blog/post/websocket-persistent-connections/, and 10.2.3 in the HTML spec https://html.spec.whatwg.org/multipage/workers.html#shared-workers-introduction)
I'm trying to write a simple app to watch over files changes and automatically reload the updated code in the browser. I'm aware of the existance of livereload nodeamon and others, i just wanted to write my own. I've created the server, let it read the file i want to read, called the watcher that kills and restart the server when changes happen in the watched file. Last part: it should refresh the browser. how is this possible?
As others have explained, the browser programming environment and thus window.location.reload() is completely separate from node.js so you cannot call that directly from node.js. Server-side code runs on the server in node.js. Client-side code in the browser runs in the browser only. The two may communicate via Ajax requests or messages sent over a webSocket connection, but they can't call code in each other directly.
For a browser to refresh based on something that changes on the server, there are two basic approaches.
Javascript in the browser can regularly ask the server if it has anything new (usually with an Ajax call that passes a timestamp). If the server says there is something new since that timestamp, then the Javascript in the browser can request the new data/file. This "polling" approach is not particularly efficient because if the data doesn't change very often, then most of the requests for something new will just return that there is nothing new. It's also not friendly for battery life.
The browser can make a lasting webSocket connection to the server. Then, when the server finds that something has changed on the server, it can just directly send a notification to each connected browser informing it that there is something new. All connected clients that receive this message can then make a normal Ajax call to retrieve the new data. Or, the new info can just be directly sent to the client over the webSocket. In either case, this direct notification is generally more efficient than the "polling" solution.
With the webSocket option, you will NOT want your server to restart because that will drop all webSocket connections. I'm not sure why you're currently restarting the server when something changes, but you will have to change that to use the webSocket solution.
NodeJS does not have a window variable that represents the global namespace. Instead it has a variable called global.
There is no browser, window or URL location in NodeJS.
It's a purely server side tool.
In node.js you have process which is a node.js global object like window which is a browser global object.
For more info type process into the node.js shell.
I'm playing around trying to find a way to communicate between two browsers on the same network to establish WebRTC without a server roundtrip (no STUN/ICE/TURN). Basically an alternative to the approach found here, where the "handshake" is done via copy/mail/pasting.
After sifting through all the cross-browser-communication examples I could find (like via cookies or WebTCP) plus a bunch of questions on SO (like here), I'm back to wondering a simple thing:
Question:
If Alice and Bob visit the same page foo.html while on the same network and they know each others' internal assigned IP addresses, are there any ways they can communicate purely with what is available on the browser?
This excludes non-standard APIs like Mozilla TCP_Socket_API, but other than that all "tricks" are allowed (img tags, iframes, cookies, etc.).
I'm just curious if I can listen to someone on the same network "broadcasting" something via the browser at all.
Edit:
foo.html will be on static server, no logic, no ICE, no shortcut.
Edit:
Still not a solution but a websocket server as Chrome extension comes closer. Example here: almost pure browser serverless WebRTC
Yes, you can establish a direct connection between two browsers over the local network using WebRTC. It requires the use of ICE, but that does not mean that an outside STUN or TURN server is needed. If the browsers are on the same network, ICE will succeed with only the local candidates of each browser.
STUN/TURN is needed only in order to guarantee that two endpoints can establish a connection even when they are in different networks and behind NATs.
In fact, if you use most of the WebRTC example applications (such as apprtc) with two browsers connected in a local network, ICE is most likely to select and use the pair of local addresses. In this case a channel allocation on a TURN server will be made, but it will not get used.
In your WebRTC application, you can disable the use of STUN/TURN by passing empty iceServers when you create the PeerConnection.
While the MDN documentation lists WebSocketServer as a client API, I don't think this is accurate (maybe they wanted to document there how to write a server).
At the moment, I know no standard way to create a server socket on a web browser. I know a couple of attacks to scan the local network but most of them rely on an active server outside the network, that is you connect to a server and get JavaScript back which opens a WebSocket connection. Via that connection, I can take full control over the client and have it open more WebSockets with local IP addresses to scan the internal network.
If internal web sites don't implement CORS correctly (see here), I can access all internal web sites where the current user is currently logged in. That is a devious attack vector which allows external attackers to browser internal documents without cracking anything. This page has a demo of the attack.
Even Flash won't let you create a server socket.
If you allow a Java applet and the Java version on the client is very old or the user blindly clicked "OK", then you can create server sockets.
Related:
Socket Server in Javascript (in browsers)?
This could be explained easily. The answer is it's not possible. In order for alice and bob to communicate at all without a third-party, at least one of them needs to be listening for incoming connections. Not possible using a standard web browser alone.
You can take a look at this
https://github.com/jed/browserver-client
I think that you can easily create an http server with javascript and send messages from one browser to another
With Nodejs you can achieve the same.