How do I broadcast messages within a network with Javascript? - javascript

The question is fairly self explanatory. I want to auto-detect my server software within a local network from a webpage. I'm able to send and receive broadcasts with node, but for this to work I need to be able to send or receive broadcasts with in-browser javascript, and then connect directly to my server.
Does anyone know how to do this? Is there a library for it, or am I out of luck?

I would heartily recommend that you take a look at coreos/etcd, hashicorp/consul or some other service discovery solution which exposes an HTTP interface and JSON data about the location of your services.
Since you cannot access the underlying networking devices from the browser (imagine if I could start probing SO's internal network from my external location), arguably, it takes as much time to set up as it would for you to write a proper Node.js application to discover resources on your network and expose these via JSON to your clients, but using proper service discovery solutions means you can take this to any kind of networking configuration your applications may be running in tomorrow under any kind of circumstances they might find themselves in whilst running (fiber optic cables got cut out between two centers, something hard fell down and broke the switch, something monopolized all the network bandwidth, the IP address of the service changes intermittently, etc.).

Related

API calls from JavaScript to backend: Ensuring legitimacy without server-side code

I want to create a Javascript widget that my users can put on their websites.
The widget is capable of creating audio, which in turn costs my users' money.
For the sake of illustration, let's say that every time a widget, placed on my user's site, is loaded by anyone on the internet (i.e. my users' users), I bill my user $1.
The widget is a Javascript code wrapped around an HTML audio player. The JS code makes a request to my backend API every time it is loaded, and upon receiving the response from my backend API, the player is constructed.
Diagram:
My concern is malicious usage by people who are not my users.
Let's say someone takes the widget's source code they found on a website that belongs to one of my users, and they put it on their site. They will, therefore, use my service but not pay for it. Instead, my actual user will pay for it (assuming I use a public API key as a way of distinguishing my users).
Usually, this is prevented by having a server-side library be responsible for any usages that might spend money. For example, I use Pusher as my WebSockets IaaS, and whenever I want to publish messages, I have to do it server-side, using their PHP SDK, with both private and public API keys.
In my use case, it's mandatory not to have a server-side library.
Question: how do I make sure that API requests I receive are legitimate?
I considered using the hostname where the widget is placed as a legitimacy measure. During the widget set-up, I could ask my users to whitelist certain (sub)domains and reject all requests that don't match the criteria, but this could be easily spoofed by, for example, a custom local domain or a CURL-crafted request.
I understand this may not be possible.
It seems like what you're asking is closely related to the topic of client side encryption. In most cases, the answer would be no, its not possible. However, in this case, it may be possible to implement something along the lines of the following. If you can get your clients to install a plugin (which you would build), you could encrypt your JS code after finishing it, and have your server serve this encrypted file. Normally, where this falls short, is that if you're sending an encrypted file, there needs to be a way for the client to decrypt it. This would require you to also serve an unecrypted JS file which would do the decoding, but by serving the unencrypted decoder you undo any security gained by encrypting your main JS file (the decryption file could be easily used to reverse engineer your encryption method/ just straight up run for people other than your intended users). Now, this is where having those API users (and the ability to communicate with them through means outside of server-client connections) comes in handy. If you build a decryption plugin, and give it to the API users (you could issue a unique decryption key for each user, but without server access implementing unique user keys would be very difficult/impossible), the plugin could then decrypt your served file in their browser, essentially guaranteeing that only users you have given the 'key' to can access your software. However, this approach has a few caveats. It implies that you trust your users enough that they wouldn't distribute the plugin (it would be against their intrest to distribute it anyway, as it could lead to higher chargers if people impersonate them). There are also probably a couple of other security concerns with this approach, however, I can't think of them right now. If any come to mind, I'll edit this post and add them.
apparently, I don't have enough reputation to comment yet, hence the post...
But in response to your post, I think that method seems much better than the one I suggested; I didn't realize you could control the API's response to the server.
I don't quite understand which of the following you mean:
a) Send a JS file to the user, with the sole purpose of determining if the player should also be sent (ie upon arriving, it pings the server with the client's API key/ url) and then the server would serve the file (in which case your approach seems safe to me, but others may find security problems with it).
or
b) Send a file with the JS and the audio player, which upon arriving, determines if the URL and API key are correct, and then allows the audio player to function normally (sending the API key to the server to track usage, not as a security feature).
If using option b, this would not improve security. If your code relies on security that runs on the client-side, and the security system was sent by the same means as the code, then almost without exception, the system designed is flawed and inherently unsafe.
I hope this makes helps, and if you disagree / have more questions, feel free to comment!
How about sending the following parameters from JavaScript widget to API backend:
Public API key (e.g. bbbe3b259f881cfc796f468619eb9d)
Current URL (e.g. https://example.com/articles/chiang-mai-thailand-january-2016-june-2016)
I will use the API key as a way of distinguishing my user and the current URL as a way of knowing which audio file to create (my widget will create an audio file based on the URL).
Furthermore, and this is crucial, I will have a user whitelist their domains and subdomains on my central site, where my users will get their widget code.
This is the same as what FB does for their integrations:
So if for example, my backend API receives the aforementioned sample URL, and the user has set up the widget to only allow URLs that belong to foo.com and bar.baz.com, I will reject the audio creation process and display an error.
Do you see any issues with this approach?

Should I track who to send notifications to when using websockets or send to all users?

I am working on a web application where users have to log in (which gives me a handle that I can track them by in the websocket server) and am wondering whether it is worth it to track them or not. I need to send out a notification to make changes to the home page only if they are on that page. Would it be better to maintain a map of everyone who is on the home page and only send the notification to them, or send the notification to everyone and then have the javascript see if they are on the home page?
Thanks for any input!
Generally speaking, Websocket (and TCP/IP) Unicasting is less resource intensive than broadcasting.
TCP/IP doesn't really allow broadcasting, so broadcasting is implemented by iterating over the connections and sending each one a message (unicasting).
Having said that, the server's code might be better optimized than your own, so you might get better performance while broadcasting under some circumstances than if you iterated over the connections yourself to run some code on each one. This would be the exception rather than the rule.
Some websocket libraries in the wild have a PUB/SUB feature, which let you subscribe connections to a channel that you can publish specific content to.
Knowing whether or not such a feature runs well with respect to performance (etc.), would requires some research into the specific library.

Can a browser communicate with another browser on the same network directly?

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.

Peer to Peer, Javascript Games

I am writing a simple javascript game for a webpage. I am going to convert it to the desktop using tidesdk. I would like to allow players on different machines to play each other without the need to communicate through a server.
Is this possible in general? Is this Sockets?? Do you have any links of this being done with javascript code?
Is this possible with TideSdk? Do you know of any links to examples of this being done wiht TideSdk?
How do the players know what ip address/port their machine is on so they can give it to the other player?
I am sorry these are vague and open questions, but I don't really know where to start looking for this stuff, as I don't really know what the stuff I am looking for is called.
... Oh, and I don't want to use any third party stuff if I can help it. Maybe the jquery at a push.
This would be impossible with the APIs provided by web browsers (you would need to use something like Socket.IO and communicate through a server, as others have said). Fortunately, since you are using TideSDK, it is possible as long as you don't need a lot of network efficiency. You will need to provide a server, but it will not have to be powerful enough to host the actual games.
The General Client and Server Method
There are other ways to organize a network, but you can look those up if you think they'd be easier to implement.
Your server will host the actual game download and provide matchmaking capabilities. The clients that people download will contact this matchmaking server to find others who want to play.
The matchmaking server should select one of those clients to be a host for the others. Finally, the matchmaking server will tell the client selected as a host that it is the host and give it everyone's connection information (ports and IP addresses) while giving the other clients the connection information for the selected host. The host will connect to the other clients.
The host computer will be the only one that actually does any processing of gameplay, and the other clients just display whatever information the host sends them. The clients render the current state of the game from each player's perspective on their respective computers and capture user input, which is sent to the host for processing.
Implementation
TideSDK provides a Ti.Network.TCPSocket object which can make raw TCP client connections to TCP servers. Unfortunately, it does not also provide a way to make raw TCP servers. Instead, TideSDK provides a Ti.Network.HTTPServer object, which implements the HTTP protocol server over TCP, and a Ti.Network.HTTPClient object, which provides an HTTP client (it is actually just an abstraction over the normal AJAX request API). You can use the provided HTTP server on the host computer and directly connect to it on the clients using the provided HTTP clients. Data will be exchanged using the HTTP protocol. As far as I can tell, this is your only option here.
I did not find any example code out there (beyond what is in the TideSDK documentation) but you might find some if you are really interested.
Next Steps
If I wanted to go ahead with using TideSDK, I would do the following:
Tell the developers of TideSDK that you are interested in a TCP server socket. A raw TCP connection would be much faster than HTTP.
Test out the HTTP connection and find out if it is fast enough for my game.
Yes it's possible in general, and sockets are what you need. Although I don't think it's possible in practice, here's why.
Normally in a P2P game, there would be a server that knows who is online, and what their IP is. When new players connect to the server they will see a list of other users, they can select who they want to play.
Without having the server, there will be no way for users to see who is online, and to answer your 3rd question:
How do the players know what ip address/port their machine is on so they can give it to the other player? It doesn't matter if they can find their own IP, they have no way to find the IP of the opponent (without calling them on the phone :)).
So, if you want to build a game, then you'll need a server. I suggest Node.JS alongside Socket.IO

Detect if user is accessing my network (WIFI) using NodeJS

My question is a NodeJS newbie question. I would like to somehow detect if a user is accessing my network (Wifi) and I would like to indicate the users presence in my network.
How would I go about identifying the user presence. I'm completely clueless as I was unable to find any library that could help me detect this in Node. Is this even possible? If so could you point me to the appropriate libraries and the approach that I need to use.
If you run a router like a Linksys, etc. that can support DD-WRT, you can flash that firmware and then use either SNMP or web page scraping to get connected clients. There are node.js libraries for SNMP and there are a ton of examples of web page scraping with Node.JS.
Alternatively, you could get really complicated and add in RADIUS authentication to your DD-WRT installation and watch for an authentication event.
Another option, you could send ICMP (Ping) packets to every potential address that your router would acknowledge. e.g. if it's 192.168.1.1 on a 255.255.255.0 subnet, you would have 253 addresses to ping. Of course, the connecting user's machine would have to have ICMP responses turned on (which they typically do by default).
I hope one of these suggestions helps.

Categories