Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
Isn’t that an interesting header!? What on earth has this NGINX (pronounce as “engine-x”, “engine-ex”, or “EN-jin-EKS”…whatever!) to do with our beloved platform? Well, maybe you saw already our new proposition on “AppWorks strategic hosting” where we help you with a supported AppWorks demo environment for your customer proof of concepts or building that fabulous demo to showcase your offerings. When we do things, we do it right; And because this hosting happens publicly on the interwebs it’s time for me to make it secure with a so-called “Reverse Proxy”. If you never heard of it (as I did since last month), continue reading…you’ll learn the why?, when?, what?, where?, and how? on this interesting technique…
Let get right into it…
Let’s first dive into some basic questions before doing all the sweaty work (It’s currently too hot 🌡️ here at my place!)
❓ What is a reverse proxy?
1 | A proxy server is a go‑between or intermediary/gateway server that |
This is the resource of my information
❓ Why do we even want a reverse proxy?
1 | Protection from attacks - With a reverse proxy in place, a web site or |
This is the resource of my information
❓ Who can deliver a reverse proxy?
In my opinion there is only one package delivering a reverse proxy best; And that’s NGINX. I see it also in use at big companies, so it’s time to do some research on it. We use the open-source version which is free of charge…As far as I can see.
❓ What about load balancing?
Well, as we’re in the NGINX comparison space we might as well dive into the load balancing part too. Not for this post, but I will place it on my backlog for a future post.
The plan
My images run locally on “Oracle VirtualBox”, and I can access AppWorks/OTDS via these URLs:
AppWorks platform:
- http://192.168.56.107:8080/home/appworks_tips/wcp/sso/login.htm
- http://192.168.56.107:8080/home/appworks_tips?authID=null
- http://192.168.56.107:8080/home/appworks_tips (defaults to OTDS login!)
- http://192.168.56.107:8080/home/appworks_tips/app/start
- http://192.168.56.107:8080/home/appworks_tips/app/admin
- http://192.168.56.107:8080/home/appworks_tips/services
OTDS:
- http://192.168.56.107:8181/otdsws/login
- http://192.168.56.107:8181/otdsws/api/index.html?v1
- http://192.168.56.107:8181/otds-admin
What I want to accomplish is to ‘Hide’ the port and IP address here; We would like to work with a nice URL like this: http://demo.myawpdomain.nl/home/appworks_tips
The installation part
My posts always start with a clean VM image based on RHEL, so boot it up and login with MobaXTerm (I have a sysadmin
account to work with)
Just to inform you, my local images don’t have any firewall applied as I want to have an open play field. On the internet that’s a different story (not for this post), but make sure you tighten all barrels as it’s a big bad world out there…
Time for the installation of NGINX (or is it Nginx?, or nginx?…whatever!)…
1 | sudo dnf install nginx |
Now NGINX will present you the introduction page on: http://192.168.56.107 (default on port 80!)
Great, “one small step for mankind, …”! 🚀
The configuration part
The first thing is to set (locally) your ‘hosts’ file with a value like this: 192.168.56.107 demo.myawpdomain.nl
. After saving it, you can type demo.myawpdomain.nl
in your browser which shows you again that NGINX introduction page like before.
In Windows 10 your
hosts
file is found here:c:\Windows\System32\Drivers\etc\hosts
; Edit it with administration permission!
On the global internet, you do this exact same trick in the DNS settings of your domain provider; This will be a new A-record pointing to your public IP!
Now, let’s try to call this URL: http://demo.myawpdomain.nl/home/appworks_tips ; The result is an NGINX error: The page you are looking for is not found.
So, NGINX requires some configuration…I guess? Let’s start with this CYA move-command: sudo mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf-distro
; After it, you create a new configuration file with sudo vi /etc/nginx/nginx.conf
where we need to make this content in place:
1 | worker_processes 1; |
What does this file do? Well, really simple! It listens for an HTTP request with this URL demo.myawpdomain.nl:80
; Looks familiar…correct? Then it passes the correct header element from the request into it (which are received from your remote call…Your browser!); It then searches for a matching location; Like /home/appworks_tips
and plots the remote requests to its internal server name which is (from the server perspective) our localhost (or 127.0.0.1
).
worker_processes
is (I think) the number processes on the server to manage parallel incoming requests (should equal the number of CPUs)worker_connections
is (I think) the number of simultaneous open connection possible.See here for more options
…
Let’s save this file and have a check if the file is in a correct format: sudo nginx -t
; If so, you can restart the service: sudo systemctl restart nginx
Now go back to your browser and type: demo.myawpdomain.nl/home/appworks_tips
…Ohwwwww mama!! 😍
BUT!!! Boy-o-boy…there we go again!
Because I’m behind an OTDS instance, my page gets forwarded to OTDS; To be more specific, this URL: http://192.168.56.107:8181/otdsws/login
! That wasn’t part of the plan…The IP and port should be hidden! So, now what? Well, that’s part of the security administration of your organization! So, login the old way…Via the IP URL: http://192.168.56.107:8080/home/appworks_tips/
, open the ‘Security Administration’ artifact, and edit the ‘Authenticators’ details:
Update the public OTDS login URL with this value: http://demo.myawpdomain.nl/otdsws/login
Now, hit the logout button and see your request being redirected nicely to the correct domain URL!
Notes:
- Try a new browser or tab if it still shows an IP
- It could be OTDS is not accepting your new domain URL…You can make it trusted here (http://192.168.56.107:8181/otds-admin/):
…
Have also a look in the developer console of the browser. A closer look at the request headers tells me we’re on a good track here:
Logging
Yes please…
1 | sudo tail -999f /var/log/nginx/access.log |
Yes, that’s a “DONE” where we implemented an amazing technique called “Reverse Proxy”. I have a much better understanding and feeling why that’s a feature you want to be familiar with; especially when you’re publicly exposing services on the internet. You can also use this within your own local network what I also see happening at larger companies. There is nothing more to add for this post, so have a great weekend and I see you in the next one.
Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?