If you wish to use a Reverse Proxy in front of your web server, you'll need to take a few extra steps to make it work.
A typical Reverse Proxy scenario looks like this:
Internet Reverse Proxy Server (Public & Private IPs) Web Server (Private IPs)
The Reverse Proxy Server is functioning as a reverse proxy (Nginx, Squid, Apache's Mod_Proxy, or Varnish).
In most deployments the Reverse Proxy will perform HTTP to HTTPS redirection and only pass requests and responses via HTTPS to the remote client.
Client HTTPS Reverse Proxy Server HTTP Web Server
Client HTTP Reverse Proxy Server HTTP Web Server
Client HTTPS Reverse Proxy Server HTTPS Web Server
In the above scenario the generated HTML will reference
http:// instead of
https:// for all assets. This causes most browsers to throw security warnings and refuse to display the content. (Typically, you'll see mixed content warnings because the browser won't load insecure elements on an SSL page.)
This assumes that your Reverse Proxy Server and Web Server are correctly configured and working properly. Meaning you have other correctly functioning Applications behind the proxy and the Web Server for Snipe-IT works properly if accessed directly.
Snipe-IT needs to be made aware of the presence of the Reverse Proxy Server. The
X-Forwarded-Proto header should be passed from the Reverse Proxy Server to the Web Server.
In Nginx, you would use:
proxy_set_header X-Forwarded-Proto $scheme;
With Apache's Mod_Proxy, you would add:
RequestHeader set X-Forwarded-Proto "https"
to your virtual host configuration.
.env file, find the entry for
APP_TRUSTED_PROXIES. It looks something like this:
and enter the IP address(es) of your Reverse Proxy. Note that IPs and CIDR Notation are accepted.
You may also want to see the Security Notes for additional steps you can take for SSL configurations.
Updated almost 4 years ago