-
Notifications
You must be signed in to change notification settings - Fork 18
Using UI3 with a reverse proxy server
UI3 is fully compatible with reverse-proxy servers as long as they are configured correctly.
I have written a reverse proxy server called WebProxy which is fully configurable via a web-based graphical user interface. It can also manage LetsEncrypt certificate creation and renewal with no third-party tools required.
Nginx is commonly used as a reverse proxy server due to its high performance and popularity.
Here is an example nginx configuration:
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name hostname.com;
# When receiving an HTTP connection on this port, redirect to HTTPS
error_page 497 https://$host:$server_port$request_uri;
ssl on;
ssl_certificate /etc/ssl/nginx/cert.pem;
ssl_certificate_key /etc/ssl/nginx/cert.key;
ssl_protocols TLSv1.3 TLSv1.2 TLSv1.1 TLSv1;
location / {
proxy_pass http://x.x.x.x:81/;
proxy_http_version 1.1;
proxy_buffering off; # Prevents low-bandwidth streams from stuttering
tcp_nodelay on; # Helps keep delay at a minimum when streaming
proxy_set_header X-Forwarded-For $remote_addr;
}
}
To use this configuration, you must edit the values of the options server_name
, ssl_certificate
, ssl_certificate_key
, and proxy_pass
to suit your environment. Additional configuration advice is below.
One complication of reverse proxy servers is that all the incoming traffic looks like it is coming from the proxy server. This can have unwanted side-effects on connection monitoring, logging, LAN authentication, etc.
The example above configures nginx to inject an X-Forwarded-For
header into web requests to Blue Iris. Blue Iris has a corresponding option Use X-Forwarded-For headers
in Blue Iris Settings > Web server tab, Advanced. If you enable this option, Blue Iris will read each client's true IP address from the X-Forwarded-For
header. Do not enable this option until you have locked down access to Blue Iris's web server so that only the proxy server (or other trusted LAN hosts) can access it. A malicious attacker with direct access to Blue Iris's web server could fabricate X-Forwarded-For
headers to fool Blue Iris into believing the traffic was coming from a trusted IP address, thereby bypassing authentication in some cases.
auth_basic "Username and Password Required";
auth_basic_user_file /etc/nginx/.htpasswd;
The two lines above can be added to the site configuration file to tell nginx to require HTTP basic authentication (user name and password). This is something you might want if, for example, you do not trust the security of Blue Iris's web server and desire an additional layer of protection. If you wish to use basic authentication, you will need to set up the .htpasswd file referenced in the configuration. See this for more information: NGINX Docs | Restricting Access with HTTP Basic Authentication
Use the latest version of Blue Iris 5 for full support of virtual directories. Limited support is available in earlier versions, primarily causing issues when logging in or out.
You may configure your proxy server to host Blue Iris under a virtual directory by changing the location /
line of the nginx configuration to something like location /blueiris/
. Be careful to include a /
before and after your virtual directory name.
Then, you would access Blue Iris by including a virtual directory in the URL:
https://example.com/blueiris
or
https://example.com/blueiris/
You must also tell Blue Iris about the virtual directory so that its automatic redirect logic can point you at the right place. In Blue Iris Settings > Web server tab, find the Virtual
setting. By default, this has a value of /
which means there is no virtual directory. To match the example above, you should enter /blueiris/
or blueiris
. Again, be careful with usage of /
.
Virtual directories are only intended to be used with reverse-proxy servers. The proxy server is supposed to strip out the virtual directory path before forwarding a request to Blue Iris, such that Blue Iris never sees the virtual directory path in an incoming request.
UI3 streams H.264 video through a long-running HTTP request (using the Fetch API to stream the response). This streaming method will fail if the proxy server attempts to store-and-forward the response, because this response was designed to be smoothly streamed in realtime. Fortunately, it is rare for a proxy server to do this by default.
The example configuration above sets some nginx options proxy_buffering off;
and tcp_nodelay on;
to keep streaming smooth with minimal delay.
UI3 loads video, images, and other data with a number of different methods, and some of them can be broken if you configure your proxy server to add a Content-Security-Policy header to responses without appropriate directives for UI3. If you get playback errors or missing thumbnails and such, your browser's developer console will probably tell you what is wrong. However it is also possible for the failures to be silent if they happened within a 3rd-party library that swallows error messages. Notably, the Vue.js framework used by the Timeline requires the unsafe-eval
directive, otherwise UI3 will fail to start because the Timeline gets stuck loading with no error message.
It is easiest to just not inject a Content-Security-Policy header. That said, this appears to work, although I have not exhaustively tested with it:
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; img-src 'self' data:;
Here is an nginx configuration line to add this header (add it to the server {}
block):
add_header Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; img-src 'self' data:";