I have a websocket that sends some messages to my server and I would like to find out what code is causing the messages to be send.
I can see the websocket and its messages by opening the chrome devtools, going to the network tab, looking for the request of type websocket, clicking on it and going to the tab messages. When looking at the requests in the network tab itself, they have a column Initiator, which links to the code having initialized the request, the same sadly isn't true for the messages overview.
How can I get the same information for each individual message?
Not possible now in Network panel now. I've created a feature request for the Chrome DevTools team in https://crbug.com/1348694. Please leave additional comment on your use case there.
However, one thing you can try is to use debug(function) in the Console, to break on everytime when message is sent. In your case, it could be debug(ws.send).
https://developer.chrome.com/docs/devtools/console/utilities/#debug-function
Related
In my angular application if I go to dev tools network tab I will be able to see the response and request coming from the back end.
Do anyone know how to hide or mask this data, is this possible if I do the server-side rendering?
Requests will be shown.
This cannot be stopped, the application is making requests and this will be logged to the network tab by the browser, as mentioned in the comments, if there are security concenrns you should be handling this a different way. Do not send data to the client that they should not be allowed access to in the first place.
To try and ensure security run over HTTPS on the off chance to data gets intercepted, that way it will not be usable data. Most data, as mentioned in the comments, will be provided by the user. Meaning in should not need to be hidden within the network tab.
Worst case scenario, someone physically sits at their computer and reads what is in the network tab, but this is a scenario that cant be accounted for when developing applications. You could base64 encode data that is being sent to and from so it is less readable to anyone who should see the network tab. Here are some resources to have a look through related to the question.
HTTPS summerised // base64 encode // Angular's security section
I've been implementing a WebSocket with JavaScript and I have this one problem:
The endpoint that my web-application is connected to doesn't send back a close control frame when I'm sending it one.
This isn't that bad because browsers close the WebSocket connection after a while.
But a few things to notice are:
Browsers do only allow a specific amount of WebSockets to be connected at the same time.
When refreshing the web-application a new WebSocket is created
This causes the problem on IE:
When refreshing the web-application more than 6 times, a WebSocket connection cannot be made.
It seems like IE doesn't "delete" the WebSockets if they haven't been closed cleanly. And what's odd is that the amount of web sockets never seems to decrease by refreshing or just by waiting.
Only by closing the browser window, or the tab resets the number of WebSockets to 0.
I've done some researching and this is what I've found out:
Browsers do only support a specific amount of WebSockets to be connected at the same time.
IE supports 6 websockets to be connected [link]
Chrome supports 255 websockets to be connected [link].
And socket.onclose() isn't triggered when you do socket.close(), it is called when the endpoint responses with a close message. [link]
IE waits 15 seconds for the endpoint to send the close message [link].
Chrome waits for 60s for the responding message [Sorry, no link for this, found this out by testing].
If no response message is received, the browser closes the WebSocket connection and a TimeoutError should occur.
Please correct me if I'm wrong :)
I've tried to use unbeforeload to disconnect from the endpoint in hope that the browser would close the connection after a while, but with no luck. [link].
It can also be the cause of that IE aren't able to do request inside the unbeforeload function [link].
Question:
Is there any way to reset the number of WebSockets that are
connected in the browser to the endpoint with JavaScript?
Is there a way to disconnect a WebSocket from the endpoint immediately without closing the connection cleanly?
Is the only way to get this to work to inform the ones who host their endpoint make some changes so they do send a closing frame back?
Is there anything I've misunderstood or that I could try to get this to work?
Here is (in my opinion) good documentation about the WebSocket protocols if somebody would like to read more about it [link1] [link2].
UPDATE:
Only by refreshing the web-application on IE the WebSockets don't get destroyed.
If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.
If it is just an edge case problem, then using a http fallback might be your only option. I guess you already do this for proxy servers that block socket connection away.
There is just 1 idea to verify (unconfirmed). Unfortunately, don't have access to IE to verify.
Application may open websocket connection in WebWorker/iFrame. During page refresh, "websocket connection scope" will be deleted, and connection is freed
EXPLANATION
This content from the question body:
Only by refreshing the web-application on IE the WebSockets don't get destroyed. If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.
Says that Websocket connection is not destroyed ONLY when page refreshes. During normal navigation, everything is OK.
So, if websocket connection is opened within other scope which will be deleted during page reload, then hopefully connection will be destroyed.
I am developing a game using SocketIO and NodeJS. However, the game currently sends too much data and I would like to figure out why by checking the data being sent every frame. How can I do this?
Open up Chrome's inspect element. Go to the network tab. Enter into the filter tab websocket and you should see a websocket item in the list. When you click on that you can then see "frames". That'll show you the data that socket.io is sending across websockets.
var socket = io();
...
socket.on("channel_data_is_being_sent_on",function(data){
console.log(data);
})
this will log all data being received by the client, from the server, in your console - which you can access in developer tools, generally F12.
I am wondering how I can see exactly what webrequests I am receiving from Facebook?
Lets say that we are on Facebook event and I want to invite all my 1000 friends.
I start clicking all my friends one by one and at some point Facebook sets a limit of 498 and then I continue to do all the clicks until I reach 498 and then it says you cant invite anyone else.
Facebook to do this at some point sends back an ajax.php page as a packet and sets this limit. This ajax php page i'm trying to find somehow.
I've tried some ajax jQuery capture Chrome extensions but I dont quite understand them much.
Do you have any idea of how I can track any ajax php request from Facebook to my browser to set this limit?
I am using Chrome Extension Live HTTP Headers
and this shows me anything that Facebook webrequest is "POST" in my browser.
But i dont think its actually all of them.
Because its only loading the photos of the chat
and some thread updates.
Here is a video of what limitation is showing in my frame of friends invite in facebook.
Youtube Video Here.
Press F12 and find the network requests section of your browser's dev tools.
http://www.devtoolsecrets.com/secret/general-finding-the-development-tools.html
I think you are misunderstanding the process. Web servers don't send requests to web browsers. They only respond to requests sent from the web browser.
When you click to invite friends you are sending an ajax request to Facebooks server. That ajax request passes the information about the event, you and your friend to a method on the server. Part of that method is to check and see if the limit on invitations has been exceeded. If not it sends your invitation and sends a response to your ajax request showing this person was invited. However if the limit has been reached the invitation is not sent and the response comes back from your ajax request stating that the limit has been exceeded.
If you know what your doing, you use Chrome or Firefox developers tools to debug javascript and follow the ajax request to the server and the response from the server. But this is difficult with the minified javascript. There are tools to deminify the javascript making it easier.
However, if you're looking for a way around the invitation limit. It's not going to happen. This all occurs on the Facebook servers to which you do not have access.
Try to use Fiddler (http://www.telerik.com/fiddler). With Fiddler you can see all requests (also HTTPS requests with an intermediate certificate), modify those or simply replay requests. It's worth a try and a must have for each web developer
I am using some comet techniques including long polling and forever frame. I am using iframes for cross subdomain stuff. The one issue that I ran into while implementing these techniques is when a user refreshes a page or navigates to another page causing a new request, the comet connection is kept open from the old page. My server (tornado) never receives a connection close and from my limited wireshark abilities I don't see any TCP fin packet sent. However, when I close the the browser, the sockets are closed at that point.
These abandoned open connections are just using up memory on the server side for no good reason. Also it causes problems when the server sends some message to the open socket and IE then correctly displays an error message: "Can't execute code from a freed script". So IE is trying to execute code on the old window which was navigated away from. How are other people handling this issue? Should I use onbeforeunload to somehow close the connection?
You could restart an open connection every now and then from the client side and if the request did not come in to the server in the specified time-frame you can safely close the old connection.