Difference between revisions of "Apache Reverse Proxy"

From Universal Devices, Inc. Wiki
Jump to: navigation, search
m
m
Line 1: Line 1:
It is possible to configure Apache to perform a reverse proxy function to the ISY - including support for websockets. It's not completely useful - since the SOAP subscription used by the admin console and Mobilinc is not supported by Apache. This configuration works well with [https://play.google.com/store/apps/details?id=com.linuxjet.apps.agave Agave] - and allows a very speedy SSL connection to be achieved.
+
It is possible to configure Apache to perform a reverse proxy function to the ISY - including support for websockets. It's not completely useful - since the SOAP subscription used by the admin console and Mobilinc is not supported by Apache. This configuration works well with [https://play.google.com/store/apps/details?id=com.linuxjet.apps.agave Agave] - and allows a very speedy SSL connection to be achieved, once you add SSL to the virtual.
  
 
Apache needs to have the following modules enabled:
 
Apache needs to have the following modules enabled:
Line 8: Line 8:
  
 
First, some assumptions....
 
First, some assumptions....
You have a SSL virtualhost (lights.domain.com) that is going to serve as a proxy to your ISY (IP is 192.168.1.2) using HTTP. You have an SSL certificate (issued in this case by AlphaSSL - good cheap certs - see [http://www.garrisonhost.com/ssl-certificates/alphassl.html this link]).
+
You have a SSL virtualhost (lights.domain.com) that is going to serve as a proxy to your ISY (IP is 192.168.1.2) using HTTP.  
 
The directory on your server assigned is /var/www/lights.
 
The directory on your server assigned is /var/www/lights.
You can place your own pages in /var/www/lights/custom (for instance, the websocket example).
+
You can place your own pages in /var/www/lights (for instance, the websocket example).
 
This example forces authentication - and injects the correct authorization header when presented to ISY. This means you can use different credentials for this site - or even multiple user accounts.
 
This example forces authentication - and injects the correct authorization header when presented to ISY. This means you can use different credentials for this site - or even multiple user accounts.
  
Line 16: Line 16:
  
 
<pre>
 
<pre>
<IfModule mod_ssl.c>
+
<VirtualHost *:80>
<VirtualHost *:443>
+
  ServerAdmin webmaster@lights.domain.com
        ServerAdmin webmaster@lights.domain.com
+
  ServerName lights.domain.com
        ServerName lights.domain.com
+
  DocumentRoot /var/www/lights
        DocumentRoot /var/www/lights
+
  ProxyRequests Off
        ProxyRequests Off
+
  ProxyPreserveHost On
        ProxyPreserveHost On
+
  KeepAlive On
        KeepAlive On
+
  KeepAliveTimeout 5000
        KeepAliveTimeout 5000
+
  ProxyVia Off
        ProxyVia Off
+
  <Proxy *>
        <Proxy *>
+
    AuthName "Authentication Required"
                AuthName "Authentication Required"
+
    AuthType Basic
                AuthType Basic
+
    AuthUserFile /etc/htpasswd-isy
                AuthUserFile /etc/htpasswd-isy
+
    AuthGroupFile /dev/null
                AuthGroupFile /dev/null
+
    require valid-user
                require valid-user
+
    Order deny,allow
                Order deny,allow
+
    Allow from all
                Allow from all
+
  </Proxy>
        </Proxy>
+
  RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxx"
        RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxxxxx"
+
  ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
        ProxyPass /custom !
+
  ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
        ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
+
  ProxyPass /rest http://192.168.1.2/rest
        ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
+
  ProxyPass /WEB http://192.168.1.2/WEB
        ProxyPass / http://192.168.1.2/
+
  ProxyPass /USER http://192.168.1.2/USER
        CustomLog ${APACHE_LOG_DIR}/access.log combined
+
  CustomLog ${APACHE_LOG_DIR}/access.log combined
        ErrorLog ${APACHE_LOG_DIR}/error.log
+
  ErrorLog ${APACHE_LOG_DIR}/error.log
        SSLEngine on
+
        SSLCertificateFile    /etc/ssl/certs/wc.domain.com.pem
+
        SSLCertificateKeyFile /etc/ssl/private/wc.domain.com.key
+
        SSLCertificateChainFile /etc/ssl/AlphaSSLchain.crt
+
 
</VirtualHost>
 
</VirtualHost>
</IfModule>
 
 
</pre>
 
</pre>
  
Line 64: Line 59:
 
</pre>
 
</pre>
  
This will proxy everything back to the ISY - with the exceptions of the websocket subscription (handled separately) and /custom (simply allowed to be served by ISY).
+
This will proxy certain paths back to the ISY - with the exceptions of the REST endpoints, the /WEB and /USER paths (allowing UDajax and HAD to function, as well as custom web space on the ISY itself).
 +
 
 +
You should wrap this in SSL!  Otherwise - you are sending password in plain text. This is beyond the scope of this article though.

Revision as of 14:57, 2 July 2016

It is possible to configure Apache to perform a reverse proxy function to the ISY - including support for websockets. It's not completely useful - since the SOAP subscription used by the admin console and Mobilinc is not supported by Apache. This configuration works well with Agave - and allows a very speedy SSL connection to be achieved, once you add SSL to the virtual.

Apache needs to have the following modules enabled:

  • mod_proxy_wstunnel
  • mod_proxy

Please note: mod_proxy_wstunnel is only (officially) available for Apache 2.4. It has been backported to Apache 2.2 - but you'll have to compile it yourself. See this article for details on how to do this.

First, some assumptions.... You have a SSL virtualhost (lights.domain.com) that is going to serve as a proxy to your ISY (IP is 192.168.1.2) using HTTP. The directory on your server assigned is /var/www/lights. You can place your own pages in /var/www/lights (for instance, the websocket example). This example forces authentication - and injects the correct authorization header when presented to ISY. This means you can use different credentials for this site - or even multiple user accounts.

Make sure to set the Authorization header to be correct for your ISYs credentials.

<VirtualHost *:80>
  ServerAdmin webmaster@lights.domain.com
  ServerName lights.domain.com
  DocumentRoot /var/www/lights
  ProxyRequests Off
  ProxyPreserveHost On
  KeepAlive On
  KeepAliveTimeout 5000
  ProxyVia Off
  <Proxy *>
    AuthName "Authentication Required"
    AuthType Basic
    AuthUserFile /etc/htpasswd-isy
    AuthGroupFile /dev/null
    require valid-user
    Order deny,allow
    Allow from all
  </Proxy>
  RequestHeader set Authorization "Basic xxxxxxxxxxxxxxxxx"
  ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
  ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4
  ProxyPass /rest http://192.168.1.2/rest
  ProxyPass /WEB http://192.168.1.2/WEB
  ProxyPass /USER http://192.168.1.2/USER
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  ErrorLog ${APACHE_LOG_DIR}/error.log
</VirtualHost>

Create a .htpasswd-isy file:

htpasswd -c /etc/htpasswd-isy username

Set your proxy authentication password when prompted.

Place the following .htaccess file into /var/www/lights:

AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/htpasswd-isy"
Require valid-user

This will proxy certain paths back to the ISY - with the exceptions of the REST endpoints, the /WEB and /USER paths (allowing UDajax and HAD to function, as well as custom web space on the ISY itself).

You should wrap this in SSL! Otherwise - you are sending password in plain text. This is beyond the scope of this article though.