Proper way to connect two NodeJS servers - javascript

I am trying to build an app to retrieve data from a local database, The structure of the app that I have a mobile app, server(on a hosting service), and local server(on my pc), I am trying to make the mobile app request data from the server via a normal HTTP request then the server request the data from the local server but the problem that I could not be able to connect with my local server I believe that I could not connect to my local server because my local server does not have a public IP, so I am trying to find a better way to achieve my idea.
I read something about Websocket but I don't know if it suitable for my idea beacuse it is Bi-directional connection and It most used for chatting app
I want to build the app with NodeJs, so what should I do to implement this idea, and thank you for the help.

Each server is on a different network the main server is on Heroku host and the local server is on my personal computer
Life would be a lot easier for you if you move your local server to Heroku where they can much more easily and securely talk to one another.
You can't connect from your Heroku server to the server on your private local network because it is behind a firewall in your home router. To allow such a connection, you have to configure a known public IP address for your home network (that won't change or use DDNS if it can change) and configure port forwarding in your firewall/router so incoming connections from the internet on a specific port can reach your local server. You will then have to harden your local server against random internet attacks since it will then be open to the internet.
One other possibility is that you could have your local server connect to your Heroku server (perhaps with a webSocket connection using some sort of secret credential). Since your Heroku server is already reachable from your home network, this would require less networking configuration change. Depending upon what you're trying to do between the two servers, you could either have the local server just make a regular http request to the Heroku server (either sending data or asking for data) or you could make a webSocket connection and then data can be sent either way of the webSocket connection.

Related

IBM Websphere - Websockets (wss) - Connection to a websocket server in other profile

Good afternoon,
I come to request support here to try to understand a behavior that I have noticed in my application and that I cannot explain the reason why it happens.
Settings
I'm using Webshepere, version 9.0.0.11, in which a spring mvc application is running over HTTPS in a profile. This application performs the definition of values ​​in session (HttpSession), so that later, through the JSP, it is possible to obtain this data to be displayed in the browser.
On the client side, through js, a connection is made via WebSocket. The WebSocket server is located in another WebShepere profile.
Unexpected behavior
Whenever the websocket connection is successfully performed, all session data is deleted. Only the data that was recorded after successful connection is kept.
Additional data
If the WebSocket Server is installed in the same profile, the reported behavior no longer occurs, and the application works as expected.
if the application uses HTTP, the behaviour isn't presente.
on wildfly server, even with HTTPS, the behaviour is as expected, that means that session data isn`t deleted.
Default configuration
Application Address: https://myappurl:9444/
webSocket Server address: wss://myappurl:9450/websocket
After tests carried out, it was found that as the connection to the websocket was made to another port on the same domain, an override of the cookies was being carried out, thus eliminating the session data.
The solution went through, in the webshere's profile where the websoket server is located, changing the parameterization of the cookie name in the session management, from the default (JSESSIONID) to (JSESSIONIDA).
Path: Application servers > server1 > Web container > Session management > Cookies

Allow remote server to access API server on localhost

I'm trying to do some home automation with my Raspberry Pi.
Right now I've set up a Node+Express API server (address http://192.168.100.100:3000, local folder ~/api), used to send the signal to a Air Conditioner and get the info from it.
Aside I've built a webapp with Vuejs to manage the AC, and setup a Nginx server to access the webapp (address: http://192.168.100.100, local folder ~/controller/dist).
Everything works perfectly on the local network, but I want to access to everything remotely. So I've forwarded the port 80, and I can access the webapp over the internet, but it doesn't work, because it can't access the API server.
Is it normal, and I have to forward also the port 3000, or is there a way to tell the app to look for the API on the localhost?
Both should work in the local network because everybody knows who's who. If the communication is server to server, both should work too because it's the same scenario. But if client perform Ajax to communicate to server, you should forward port 3000 too. Because the request is out of the local context (if you are out of your network).
server to server: localhost -> localhost
client(browser) to server: internet -> localhost
You could avoid the forward if server(local) perform a request to a client(remote).
You can forward port 3000, and it should work.
Another option is to use ngrok. It allows you to open a tunnel (regardless of your firewall settings) straight to your API. All you have to do it register a free account and you will be able to have a single tunnel running indefinitely. Only drawback is that you need to use their shortUrl (Like https://asdasd12.ngrok.io which changes every time you restart. You can pay to get rid of that, and get a permanent subdomain(Like https://myniceapi.ngrok.io)

node.js (with socket.io) security?

since I am learning node.js I was wondering about something:
When I use node.js server to run a websocket, so that clients can connect (like on a website via javascript), it always listens public. Isn't that a security problem, that everyone in the world would be able to send data to the ip:port. They just have to connect to the server via the data that are written anyway within javascript and send / receive data?
I was thinking about a token, which would make sense in Java or Swift etc, but in javascript it can be seen anyway?!
TL;DR: yes, It's totally secure.
Every time the browser sends an HTTP request, there is a port waiting for the server's response. The difference between this to an open port is that an open port is open for everyone on the web. In an HTTP request or web socket, the port opens only to the server.

Is a web socket connection in javascript an inbound connection?

I'm trying to make a web socket connection on my webserver. The connection is run from a client in javascript and connects to a php script on the webserver. The javascript is also placed on the webserver, but runned from a clients webbrowser.
The problem is that hostgator doesn't allow inbound socket connections unless you buy a dedicated server, but I'm not aware if this counts as an inbound socket connection.
So does anyone know if this counts as an inbound socket connection or any other web hosting sites that would allow inbound connections?
Thank you in advance :)
A websocket connection starts life as an incoming HTTP connection (usually on the same port as is being used for web requests) with some custom headers on it which is something all web servers have to be configured to accept (or they wouldn't be any use as a web server). After a brief exchange with the client, the client requests an upgrade and a switch to the websocket protocol (the initial connection was the HTTP protocol). That connection which started life as an HTTP connection then becomes a webSocket connection (if the web server agrees to the protocol switch).
So, yes it is an incoming connection to the web server, but it's an incoming HTTP connection which your web server has to already accept. webSockets were designed this way on purpose to make them highly compatible with existing HTTP networking infrastructure, firewalls, etc... so they could be used by only upgrading the HTTP server software (to support the webSocket protocol) and not changing any of the networking infrastructure.
FYI, there are other hosting issues with using webSockets. A webSocket is a continuous, long lasting socket connection. In order to use it, you typically need a continuous, long lasting server process. Many of the lower cost, shared hosting environments do not support that. They tend to accept an incoming HTTP request, dispatch it to whatever script it is supposed to run (e.g. a PHP script), let it run on that request and then the script exits and your server process does not continue to run. This works well for low cost, shared hosting because no server resources are consumed by your app when it is not actively in the middle of serving a page. But, that model won't work for webSockets where you must have a continuous server process for the webSocket to be connected to.
I don't know specifically about hostgator, but this is another issue to look into. On my shared hosting on Dreamhost, I cannot have a long running server process. On Dreamhost this requires a VPS hosting plan and from what I've read this is common for other shared hosting environments too.

Maintain a backend connection on NodeJS across page requests?

I'm making connections via thrift (node-thrift) to a backend server to make api calls, but the communication is bidirectional (push/pull) to NodeJS.
While a user is browsing around different URLs, and Node is churning out jade templates and javascript files via Connect/Express routes, how do I maintain the connection to the backend server, and output (as an example) the connection status as part of the rendered jade output?
I have the connection object, but what do I do with it?
Sockets and port communication is generally a new area for me, so any help would be appreciated.
Keep in mind that backend server is not communicating to the web browser as the client, but rather the NodeJS server as the client.
(updated after discussion in comments)
So it looks like thrift is TCP-based which means the node client is going to keep the connection to your thrift API server open. This is entirely independent of what your node/express app server is doing with the browser clients. So if you keep a reference to your thrift client available to all requests, by attaching it to the app object for example, you should be able to determine it's current status and include that information in HTTP responses to the browser. There's not going to be any automatic coordination or association of any kind between your express app server handling browser HTTP requests and your thrift client making RPC calls to the API server. If you want coordination, you need to code that explicitly, but sending an HTTP response to a browser isn't going to automatically close your thrift TCP connection to the thrift RPC server (and same story vice versa).

Categories