Reverse Proxy Support

I have a couple requests for future versions of Indigo that will really help me out.

I access Indigo through NGINX. This allows me to reach my home automation from anywhere on the Internet using SSL and my own SSL certificate. It also allows me to put multiple applications behind one interface (since I only have one IP to the Internet). Nginx handles its own authentication. That's my use case.

My problem is that Indigo only supports two authentication mechanisms: 1. No auth. 2. Digest Auth. Furthermore, the username/password created for digest auth has full access to the Indigo client as well as full access to the API. There is no way to separate that access or define which users can access what.

I've put a lot of thought into this. There are two very simple solutions to solve my problem, and if either one gets implemented I can correctly secure my home automation.
1. Allow an IP (or list of IPs) that are allowed unauthenticated access to the API. This allows me to keep Digest auth turned on, and whitelist my nginx server (and/or localhost).
2. Allow Basic Auth in addition to Digest Auth. I can spoof Basic Auth using nginx and store the credentials on that server.

That's it. Allowing a whitelisted IP sounds like it should be really easy, and I'm very hopeful something like this is added soon. I have many other ideals and suggestions for how to improve the usefulness and security of the API and client TCP ports. Hit me up if you're interested.

Thank you for reading,
-Captain

PS.

I really just want to write this other request somewhere too, even though I know it's highly unlikely to get implemented. Please add a "base path" parameter to the web server. This makes the web server more compatible with a reverse proxy. I'd like to serve the entire application on a single URI like `/indigo/`, but I need indigo to add add /indigo/ to the beginning of all html elements it serves. Grafana does this by setting the root_url variable in grafana.ini. Deluge does it by taking a client request header named "X-Deluge-Base" and appending that all resources before they're served. Lots of ways to achieve this and some may be simple to code.

[jay (support)]

Thanks for the requests. We have quite a few related and tangental requests already and we'll add these as well.

[matt (support)]

For configuring Indigo's Web server to handle reverse proxy take a look at this forum thread. The instructions are for Apache, but it also includes the IndigoWebServer.conf file change to set a root path. You can also edit the same option IndigoWebServer.conf file to enable HTTP Basic authentication.

All those workarounds aside, I do agree with you that Indigo's authentication model needs a definite overhaul. It is definitely on the request/ToDo list.

omg matt amazing! Thank you!!!!

I added this to the web server config (Indigo 7.4):

Code: Select all

[global]
app_root_path = '/indigo/'
authen.use_digest = False
authen.use_basic = True


And I added this to Nginx:

Code: Select all

      set $indigo   http://192.168.3.1:8176;

      location /indigo/ {
               auth_request     /auth-3;
               proxy_set_header Authorization "Basic dTVlcm5hbWUxOnA0c3N3b3JkMnp6eg";
               proxy_pass       $indigo$request_uri;
      }
      # Indigo Admin Pages
      location ~ ^/indigo/(variables|devices|actions|refreshingimage|server(request|command)) {
              auth_request     /auth-4;
              proxy_set_header Authorization "Basic dTVlcm5hbWUxOnA0c3N3b3JkMnp6eg";
              proxy_pass       $indigo$request_uri;
      }


The auth_request line authenticates the request against this app: https://github.com/causefx/Organizr

This is mostly working, except I think there may be a bug in the implementation. When I navigate to this URI https://host.name/indigo/editvarpage?na ... eJS%3DTrue and attempt to update the variable value I get a 404: undefined page requested. The 404 comes from here: https://host.name/indigo/variables/SprinklersActive - The name of the variable in question (as seen in the URL is SprinklersActive). The same thing happens with device controls. I can drill down into the devices, but as soon as I click on or off, I end up with a 404 at a URI like https://host.name/indigo/devices/Office%20Light. Is this a bug in my implementation, or something missing in Indigo?

Thank you!

EDIT: I had a typo in the above nginx config, and I've fixed it, but now I get a different problem. Now Indigo returns its own IP during a request instead of the Host header. It returns https://192.168.3.1:8176 as a resource for the web browser when I try to edit a variable or device. Port 8176 has no SSL, so this fails quickly. I can now edit device states, but not variables. When I edit a variable I get a redirect to the above URI that fails. When I edit a device, it works, but the web inspector shows an error to the same URI above (port 8176 w/ https). It feels like the root_path variable is missing from a few locations. Perhaps s a few locations are missing the Host header too. This is just odd...

EDIT2: It has something to do with the proxy auth I'm using. This is the only app that seems to be affected, and I cannot figure out why. If I come to a conclusion I'll post back here.

Resolution:
I have no idea why, but adding this line to both location blocks fixed everything. I can now use third party oauth to authorize access to Indigo's web interface. I've split the access levels into two for viewing and changing. Hopefully future versions of Indigo separate those paths more clearly to make that distinction easier.

I'm soooo good now. Thanks!

Code: Select all

               proxy_redirect ~^(http://[^:]+):\d+(/.+)$ https://$host$2;


To make sure my mobile clients can get in, I setup another server block and put them on their own domain.

Code: Select all

server {
      server_name       ha.*;
      listen            443 ssl;
      include           /config/nginx/ssl.conf;
      include           /config/nginx/proxy.conf;
      location /indigo {
         proxy_pass        $indigo$request_uri;
      }
      location / {
         proxy_pass        $indigo/indigo$request_uri;
      }
}


More:

Since the Indigo web server has been switched to Basic Auth, we can completely override the username and passwords allowed in using nginx's auth feature now. To do this (as shown above), add a line like this to your location blocks:

Code: Select all

              proxy_set_header Authorization "Basic dTVlcm5hbWUxOnA0c3N3b3JkMnp6eg";


The string is at the base64 encoding of the username:password - you can find lots of info on how to encode a basic auth user/pass pair on google. Adding this line allows anyone in unauthenticated. Now add a couple more lines like this:

Code: Select all

    auth_basic                 'Indigo Control Server';
    auth_basic_user_file       /etc/nginx/htpasswd;


And create the htpasswd file with the htpasswd command - also lots of info on google for this. This allows Indigo to have multiple accounts through your nginx proxy. This also keeps some level of authentication enabled on Indigo - something I had turned off for a long time before this thread. Using the example above, you can create two groups with different access levels. One for viewing and one for making changes.

Good luck!