Apache Reverse Proxy: Difference between revisions

From Universal Devices, Inc. Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
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.