A React app and Nodejs server which is used to retrieve and manipulate the data are running on the same server. When accessing the app locally it workes fine, but when accessed externally the app is visible but without data. The reason behind this is that the port on which the application is running is open but the port on which the Nodejs server is running is not.
My question is this, what is the best way to solve this issue? The simplest solution would be to open up the other port, but I am assuming that is not the most secure solution.
Any suggestions would be appreciated.
Open to port for the outside world and implement a token-based request verification system.
You can implement CSRF token verification. It always checks that request comes from a trusted source only.
Do this using a reverse proxy server, like nginx, to listen to the open https port. The reverse proxy will handle the https encryption, rather than burdening your nodejs code with it. nginx is multithreaded and can do https efficiently.
The reverse proxy passes along requests to your http://localhost:3000 nodejs. In my experience, this arrangement works very well at large scale.
Explaining how to do this is too much for a stack overflow answer. But you'll find plenty of online advice.
Related
I am having issues with running NodeJS as a backend for a React application (website) when utilizing HTTPS. The NodeJS runs on port 3001 waiting for requests. When React is running on IIS on HTTP and queries NodeJS (http://localhost:3001) everything is fine. However if I deploy SSL on the React application then the communication between React and NodeJS fails. I believe it is the security restriction of HTTPS and HTTP interacting.
The question then is, how do I run node on port 3001 but on HTTPS to deal with HTTPS origin requests?
I have looked at Reverse Proxy (https://dev.to/petereysermans/hosting-a-node-js-application-on-windows-with-iis-as-reverse-proxy-397b), looked at IISnode which doesn't seem to be supported anymore and read up on running NodeJS on HTTPS (which doesn't seem to be a viable solution).
Looking for any guidance and direction.
Much appreciated.
Ok, typical that 10 minutes after you ask, you figure it out.
This is how I resolved the issue and someone more knowledgeable might correct me.
On IIS you have your HTTPS React website
Create a second Website on IIS (that also has SSL installed so can be accessed through Https).
On this second website you install the reverse proxy solution (https://dev.to/petereysermans/hosting-a-node-js-application-on-windows-with-iis-as-reverse-proxy-397b) and route the requests to port 3001 on NodeJS application.
Effectively this means that the React application running on Https can now call NodeJS on Https (e.g. https://mynode.mysite.com) and the reverse proxy forwards the request to the NodeJS application on port 3001 (or the port that you are running NodeJs).
If I am wrong (this worked for me) or have gone the long route, please feel free to correct.
Thank you.
I am having a pretty big problem at work and would like some help. Basically I have a react front end and a node.js backend to connect to the database. The problem is that the company I am buildign this for will only open 1 port (443) for the webpage. And since react is generating on the clients side I cant use a localhost url to call the backend to get info from the database. They said they might open another port if we make it HTTPS. So I tried using express and https with a self assigned ssl certificate, which worked on my side. On the clients end the webpage's http call doesnt make it to the express server.
I have also started to build this with webpack and express, so the server will render the react code. This should work but I am suspecting a problem with webpack (have not had a good experience with it in the past).... Anyways, is there anything one of yall can think about that will allow my client rendered react app to connect to the database? How do other companies handle something like this? Really any help would be great. I have been under so much stress from this.
If you think you have any information that could help point me in the right direction, I would greatly appreciate it!
I dont think you need to open any other port to access the database, since the code that will access it will run server-side. I mean, yes the database port will need to be open locally, but it does not need to be open to the Internet.
In other words, you will need to have your react code access an API on your server (https end-point on port 443) in order to retrieve data. Your solution with Express should work. I guess you have a Node server listening on port 443, and that you are using Express as framework server-side. It is this server side code what should access the database and provide the data to https requests made by your React client-side code. Your browser might not like your self-signed certificate, and you will probably need to tell it to trust the certificate.
UPDATE:
If you want to block all ports from the server except port 443, you can use a firewall to achieve that, and make the ports look inactive, except for request coming from localhost, the server itself. If that's not an option, you could also choose to connect to the database using a socket path instead of a TCP port.
I have an API server running behind an nginx reverse proxy. It is important to have all requests to my API server be secured via TLS since it handles sensitive data.
I've setup nginx to work with TLS (LetsEncrypt) so that seems to be okay. However, requests from nginx to my API server are still insecure http requests (this is all happening across docker containers, by the way).
Is it a best practice to also setup https between the reverse proxy and the API server? If so, how would I go about doing that without over-engineering it?
It all comes down to how secure or paranoid you'd like your implementation to be. It may also depend on the type of data you're playing with. For instance: I'd definitely do this for credit card numbers or other sensitive information.
As the comments have already stated, you would typically terminate SSL connections at the front facing webserver, assuming the API backend is also inside your LAN, which you trust and control. If you want to go that extra mile, you could also set up SSL on the API backend. Details of how to do that depend on the software you're using on your backend.
If you do decide to implement SSL on the API backend, the setup would be similar to what you did to setup Nginx with SSL on the frontend, with the main difference being you don't need to use a public certificate on the backend. It can be self-signed, since no one else besides your web server will be talking to it. Then it's just a matter of fixing all the URIs in your code to use HTTPS.
I'm building a web application using the MEAN stack. The site contains authentication (using passport.js) so I would like to secure our connection with SSL/TLS.
For our deployment we're using nginx as a reverse proxy to the Node app running on the same AWS EC2 instance.
My question is: With my setup, what is the best practice way to setup an https (SSL/TLS) connection? Should I get a certificate and set it up at the nginx layer? Should I do it in my node app directly? Is there some other better way?
I've done some googling but haven't found anything profound. If anyone could point me to an article on the topic that would be very useful as well.
Thanks in advance!
First it's good to have SSL running on NGINX. So the communication is encrypted for the visitor in the first place (at least to the NGINX). If you're running Node on the same instance it's probably not absolutely necessary to encrypt also the traffic between Node and NGINX. But as soon as you have NGINX on another place running you should use SSL on Node too. As the data could potentially be accessed by Hackers.
I want to ask about some good practices. I have a Node.js (Express) web server and socket.io push server (in case technology matters). I can turn both of them into one application but I want them separated (they can communicate with each other if necessary). There are two reasons to do that:
It will be easier to manage, debug and develop the app;
It will be a lot easier to scale the app. I can just add another instance of push server or web server if necessary;
This is at least what I believe. The only problem is that when a client connects to the seperate socket.io server then it won't send cookies (different port, cross-domain policy).
The workaround I came up with is to put a reverse proxy (written in Node.js as well) in front and check what kind of request we are dealing with and send it to web server or push server accordingly. Great, now we have cookies in both web server and push server. The reverse proxy can be a load balancer which is an additional bonus.
It looks like a good idea to me. What do you think about this design? Perhaps any other workaround for cookie problem?
I recently did something simular, we initially used a node.js reverse proxy but ran into reliability/scalability problems. We found serving static files and proxying requests was best left to nginx. haproxy is also a very viable solution for stand alone proxying as well.
HaProxy
Nginix as a reverse proxy