NGINX wrapper for Omnis CGI
On Mon, Mar 19, 2018 at 11:57 AM, Nick Renders <omnis1@arcict.com> wrote:
> Hi,
>
> Thanks for the feedback, guys.
>
> I tried setting up a reverse proxy in my NGINX config that refers to the
> Omnis runtime, but I couldn’t get it working properly.
> The request actually goes through to Omnis, but for some reason it is
> handled by the Omnis Web Service.
> Our Omnis runtime runs on a different machine, but I don’t think this is
> the reason why it is not working.
Hi Nick,
Bruno wrote that you don’t even need the CGI wrapper. If that is the case,
ensure that Omnis will respond appropriately on 10.0.0.1:5912. Once you
are certain that it does, then concentrate on the nginx configuration. The
location directive is NOT intended to match specific files. This article
provides a good explanation of how to use the location directive
appropriately. <www.keycdn.com/support/nginx-location-directive/>
Here is the official documentation on it. <
nginx.org/en/docs/http/ngx_http_core_module.html#location>
Here is how the VM Configuration Django application in my project is
served. <paste.ngx.cc/e9> (That will be automatically deleted after
four days.)
I want to point out a few things.
* The backend knows nothing about HTTPS. The frontend only serves pages
over HTTPS.
* Static site assets like images, fonts, CSS, and JavaScript are served
directly via nginx due to the /static location block.
* The /media location block is not used on this project for now. That would
be for user-uploaded files and in this application, we don’t have any of
those at the moment.
* The /django-ws location block is a handler for WebSockets.
* The / location block proxies all other requests to Django, which is being
served via a UWSGI application server. E.g. if the system administrator
wants to configure the VM, he would navigate to vmconfig.example.com.
Nginx would do a redirect to vmconfig.example.com (line 7 => 12 =>
23 => 29 => and then a combination of 65 and 73). Django would check if the
user is authenticated and if not, do an internal redirect to /login and the
user would have to enter a valid username and password pair. Once
authenticated, Django does an internal redirect to /home, which presents
the user with the Virtual Machine Appliance dashboard. To render the
dashboard, every location block other than /media, is used. We’re hitting
/health-check every second and the response from that endpoint is handled
by /django-ws so that we can increment an uptime clock.
This is what /etc/nginx/proxy_params contains.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
add_header Front-End-Https on;
proxy_redirect off;
You should be able to adjust this configuration file to suit your
particular case. I would get this working without HTTPS first and then deal
with HTTPS.
When you have this working and if Omnis is on the same host, there is no
reason to have Omnis listen on anything other than 127.0.0.1 so you can
change the Omnis configuration to reflect that and make the necessary
change in the nginx location block. If Omnis is running on a different
host, you should block all requests to 10.0.0.1:5912 except from the host
that nginx is running on by firewall rules.
Regards,
Clifford Ilkay
+1 647-778-8696
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com
