I have a problem with NodeJS (I think) using a kafka node on a node-red instance installed on a RPI3.
Scenario:
I have a cluster with a running instance of Kafka. The real ip of the machine which host the kafka broker is private so I have a public ip with a public port which I can use. Then, the requests are redirected to the broker.
Testing my environment with a broker installed on my laptop (so knowing the real ip of the broker) everything works fine.
Performing an attempt on the real cluster node-red shows the problem described in the terminal:
So, I took a look in js file representing the kafkaNode I used and I find this:
I'm quite sure the problem is in these line and in the use of the ip redirection. Anyway, honestly I'm a newbie of Nodejs and javascript so I don't know if there are some bugs about use of it.
Any ideas?
P.S.: I'm sure that kafka broker is correctly running and installed. the problem is exactly in js.
I also tried to reach the "fake ip" with telnet, and it works fine.
Thanks in advance
Kafka does not work with default values configured if you use a NAT, VM, or other proxy for "ip redirection" because the clients dynamically discover the private IPs of the real kafka brokers and will try to connect directly to those IP addresses and not just the one you configure in your client for the initial connection and meta-data request.
You need to make sure that the broker is setup to advertise the hostname or IP of the machine doing the redirection or your producers will not work.
Related
This is less of a "what is wrong with my code" and more of a "is this possible or even required". I've been working on this CLI chat using socket.io and socket.io, and then I thought "what if this was a production server exposed to the internet - does this need security?"
I've seen a lot of stuff online about using nginx or express (or both) to achieve this - but no mention of any type of encryption if you were trying to do this via CLI (eg, "node file.js" for this to emit traffic to the webserver but securely). I've tried a few examples (as they were provided) and then adapted my existing code to incorporate the same config, but now I'm starting to think that perhaps it isn't possible because they are already secure? (In my understanding the server listening port is just for the server to bind client to another port to send data)
I can't seem to find a cut and dry answer (past forum posts seem to contradict each other on this) from what I've found.
I tried running my server and connecting up via 2 clients (one localhost on the same as the server and one on another IP on my LAN) and ran wireshark to see if I could see my other host (which I couldn't) but I could see unencrypted traffic being sent... So while this isn't broadcast traffic to all, how easy would this be to snoop on if you knew the exact port server & client were using to communicate?
Hope someone can help explain these nuances
The long answer is complex. The short one is:
Anything you send through a Wire is easy to spoof. This is why TCP over TLS exists. Any communication through a TLS secured channel would assure your data between client & server will be secret (as long as you trust the server you are good-to-go).
Socket.io uses WebSocket under the hood, (same as there is HTTPS for HTTP over TLS) there is WSS for WS over TLS. So if you set up your server to accept WSS (maybe only WSS to be sure there is no unencrypted connection going on) and you make sure to connect the client to a wss://.... endpoint, you have achieved client-server security. It's that simple.
If you can not trust the server, and what you are doing is essentially a message broker, you can go further and experiment with end-to-end encryption (https://en.wikipedia.org/wiki/End-to-end_encryption).
I tried to fetch JSON data from the API with http://localhost:3030/get/articles and the data was successfully displayed on my reactjs, but when I tried on another computer the JSON data did not appear, I used axios to get the JSON data. Has anyone ever experienced or been able to help my problem?
Localhost is just a local server built on your own computer machine. Which can be used to host website locally for testing it.
If you want your project to be accessible from other computer, you should install your project on a web server with registered domain name pointing to this web server.
Localhost is a local server built on your own computer to development and testing. so if you want to access your application another users, you should published to server side computer or cloud.
The problem here is that you're accessing localhost which means the local machine.
When you try to access localhost in your web browser, you're basically saying this computer. If you do it on the machine where you develop your application then it will work but on another computer it wont.
A solution to access your JSON from another machine could be to use the IP of the machine that provide the JSON instead of the localhost keyword.
Like this: http://IP_OF_THE_MACHINE:3030/get/articles.
E.g.
http://192.168.10.12:3030/get/articles
You can get the machine's IP by typing ipconfig (for Windows) in a Command Prompt.
You can use a DNS entry or edit the C:\WINDOWS\system32\drivers\etc\hosts file on Windows to avoid typing the IP address everytime.
You can run ssh -R 80:localhost:8080 ssh.localhost.run. where 8080 is your port number. Yours should be along the lines ssh -R 80:localhost:3030 ssh.localhost.run since 3030 is your port number.
When you run this in your terminal you will get a message Connect to http://dummydata.com.localhost.run. Go to that link and basically you'll get your stuff online.
Using Express when we use app.listen(port) , the app location is localhost:port/
In local machine I completely understand how we can access to this address as we use a local browser running on same machine . Even other clients running on same network can access the server.
As per my knowledge localhost or 127.0.0.1 IP can be accessed on same or other machines in same network.
But if we deploy to cloud like Heroku without adding IP option like app.listen(port, IP_ADDRESS) instead we use app.listen(port), the only thing that varies is PORT number(process.env.PORT) but IP is still localhost. So how can clients from other networks access the server?
You can use port forwarding on your router to forward router_ip:port to local_ip:port allowing you to access it externaly
Just because you are connecting to your local instance via localhost doesn't mean it is not also exposed via IP. Localhost basically says don't resolve any IP, just loop back to this computer, but your node server will still be deployed to an actual IP address. Try looking up your computer's IP address and connecting to your node server through that instead of localhost, and you'll find you're still able to communicate with the server.
When deploying to a cloud service, or any other hosting service, you'll be given an IP address associated with that instance which is what will be used for resolving. Heroku in particular will blackbox a lot of the domain-space and port-forwarding process for you.
TL;DR
In Javascript, how do you to find the IP of all servers running a specified program on a specified port in the LAN?
Background
I'm writing a server in node.js that is supposed to connect users browsers as controllers to a common device on which a game is running. The browsers are running a web app based on html and Javascript. The connection is based on socket.io.
I'd like for the web app to be able to find all available instances of this server in the LAN in order to create a server list for the user to choose from.
Is there a way to make the server discoverable by the web app on the local network in Javascript, and in that case: how?
Ideas
Have the server broadcast its IP to all devices on the LAN and have the web app listen for these messages (No idea how to do this without node on the client)
Connect to every IP on the network and see if the connection is successful. (Does not seem feasible)
Scan every IP on the network and connect only to those where the port is open. (Once again, no idea how to do this without node on the client and does not seeem feasible either.)
EDIT
The server is supposed to be portable and work independently, without any central system backing it up or providing matchmaking for clients. It is a LAN only server and should work even without internet access.
There is no way for you do this. Sorry. Since there is no exposure to UDP on client-side JavaScript, broadcasting is out of question. Any attempt on massive scanning will quickly raise flags on network monitoring software. You have to use a known address.
I'm running a game which contains a server.js backend (which is hosted and run on my localhost), and the frontend is on a github website. The github page connects to the server on my localhost through the config which points to 127.0.0.1. I realize that I will be able to play this from my localhost this way, but will other people be able to?
Basically the index.html connects to the visitor's localhost to look for the running server.
A visual representation (sort of):
[nullwalker.github.io/index.html] ----> [localhost(127.0.0.1)/server.js]
What should I do to allow myself to play from the computer that's hosting the server backend as well as others being able to play?
You would need to host it in a live environment. There are ways via port forwarding to use your computers ip (gateway) to allow others to connect, however typically ISP's will try to stop you from using your dynamic IP statically. Safest bet is to launch a cheap VPS and host it there.
http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/
This article seems to explain port forwarding well enough.
As for the VPS, you can find extremely cheap ones really easily, if you do not expect a lot of players it should be fine, if you expect more then using your own connection is dangerous.
unless they have the same server running on their localhost, no. And they almost surely don't. You should get a host (digitalocean.com is very popular and good, but there are many others), and then run it there and connect to that instead of localhost