MWareman

You don't. As you say - if you do that the secret does not stay secret! Browser based api calls use the regular URLs and will send an authorization header with their requests - based on the primary authentication to the site. The secret based access is for a service like IFTTT - so you can set it up without having to give them your actual password. This means that if they ever get compromised, your password is still safe and you don't have to reconfigure all your devices. All you have to do is change the key to re-secure it. Michael.

Here is my full config file (with certain values changed...) with the redirect from port 80 and SSL config. I got my cert from here: http://www.garrisonhost.com/ssl-certificates/alphassl.html The standard cert is fine. You don't have to use this CA though - that's up to you. Make sure the SSLCertificateFile points to the certificate, SSLCertificateKeyFile the private key and SSLCertificatechainFile to the intermediate certificate provided by the CA. <IfModule mod_ssl.c> <VirtualHost *:443> ServerAdmin webmaster@lights.domain.com ServerName lights.domain.com DocumentRoot /var/www/lights ProxyRequests Off ProxyPreserveHost On KeepAlive On KeepAliveTimeout 5000 ProxyVia Off #SetEnvIf Request_URI ^/{SECRET_KEY}/ noauth=1 <Proxy *> Require host lights.domain.com AuthName "Authentication Required" AuthType Basic AuthUserFile /etc/htpasswd-isy AuthGroupFile /dev/null Order deny,allow Satisfy any Deny from all require valid-user Allow from env=noauth </Proxy> RequestHeader set Authorization "Basic {ISY_BASE64_CREDS}" ProxyPass "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPass /rest http://192.168.1.2/rest ProxyPass /services http://192.168.1.2/services ProxyPass /WEB http://192.168.1.2/WEB ProxyPass /USER http://192.168.1.2/USER #ProxyPass /{SECRET_KEY} http://192.168.1.2/rest #ProxyPassReverse /{SECRET_KEY} http://192.168.1.2/rest ProxyPassReverse "/rest/subscribe" "ws://192.168.1.2/rest/subscribe" retry=4 ProxyPassReverse /rest http://192.168.1.2/rest ProxyPassReverse /services http://192.168.1.2/services ProxyPassReverse /WEB http://192.168.1.2/WEB ProxyPassReverse /USER http://192.168.1.2/USER CustomLog ${APACHE_LOG_DIR}/access.log combined ErrorLog ${APACHE_LOG_DIR}/error.log SSLEngine on SSLCertificateFile /etc/ssl/certs/public.pem SSLCertificateKeyFile /etc/ssl/private/private.key SSLCertificateChainFile /etc/ssl/chain.crt </VirtualHost> </IfModule> <VirtualHost *:80> ServerAdmin webmaster@lights.domain.com ServerName lights.domain.com RedirectMatch ^/(.*)$ https://lights.domain.com/$1 </VirtualHost> If you want to be able to accept API calls from IFTTT, generate a secure, random value in some trusted way. Replace {SECRET_KEY} with this value on the three lines it appears, and un-comment the lines. If the REST call was https://lights.domain.com/rest/status (needing basic auth) - then the API call https://lights.domain.com/{SECRET_KEY}/status will be successful without basic authentication. Obviously - keep {SECRET_KEY} secret! This relies on SSL and the cryptographic strength of {SECRET_KEY} for security. That being said - I'm now successfully having my Foscams trigger events on my ISY via this method... (they cannot do basic auth) - so this makes me very happy! Michael.

A php based system is still not secure without a certificate - as the authentication transaction is still in the clear. Only SSL can close this gap. For the client to authenticate to the proxy, Apache must be able to handle it before passing control to .php. that's why auth is in the .conf here. It's also important that the same username/password and resulting session is used for both the web interface and calls to the /rest interface, and the websocket connection. I doubt the php based auth will allow websockets to work at all. Michael.

There would be a port change and other changes to the httpd.conf. when I get home later I'll post the needed changes. You do also need a trusted SSL certificate - especially if you want to be able to receive IFTTT requests. I have a wildcard cert from these guys (http://www.garrisonhost.com/ssl-certificates/alphassl.html), but if your is a single name site then the regular cert will work just fine. At $15/yr it's the cheapest trusted cert I've found. I use a wildcard because I host several sites each with their own name all sharing the same certificate (for my access point management software, firewall, log correlation etc...). The .conf I use has a very simple host on port 80 that redirects to https - so a user can do either, but always end up on the secure site. I did notice during testing you have your alarm system integrated. There is more than enough info to locate you, so I'd spend the $15/yr to secure the login. Michael.

All, I have added a couple of things to the example on the wiki. The first is a line in the '<Proxy>' definition that I *highly* recommend you add. With Authentication, this are secure - but if anyone breaks the authentication (or you misconfigure it) Apache would become an open proxy. You don't want that! Please add a 'Require host lights.domain.com' (modify for your own DNS name) so that requests are limited to your specific host. That way - things are kept more secure. Second, I have rearranged the authentication rules.... to allow another feature..... You can (manually) generate a secure nonce, and have Apache proxy requests to the rest API using the nonce without needing auth at all. This is very useful for receiving incoming requests from, for example, the IFTTT Maker channel. If requires SSL though - so is an advanced use case. The three lines implementing this are commented out in the example by default. Michael.

Thanks for your kind comments Mark... I've added details into the wiki. You can actually (probably) generate the needed string directly on your RPI ("echo -n "user:password" | base64") - so you don't have to send your password off to who-knows where... To be honest - I hope that the HAD code (and UDAjax) can be enhanced with a subscription and real time updates. This is exactly the use case websockets are for! One thing (don't know if you've noticed this yet) - on first subscribing you get a dump of all devices current status. There is no need to separately get status as you are building the page. It would be useful for keeping the code there for a manual update (should it be necessary), but this might help make the load time even better. Michael.

According to http://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface#Subscriptions_.28Web_Sockets.29 - it's section 5 in ISY WS-SDK Manual. The authz_groupfile is not needed now - I've removed the line that needed it (it wasn't doing anything anyway). Off to grill now...

It's an integer variable. Dosnt it need to be a state variable for this to work properly? (I don't know - I havnt tested this in a long time!)

Great to hear!! Now - don't forget to change the password for 'mark' in /etc/htpasswd-isy (or even use a different username!) I've updated the wiki page with our findings on the needed modules... http://wiki.universal-devices.com/index.php?title=Apache_Reverse_Proxy I'm glad we got it all figured out! (BTW - a great looking site you're putting together!) Michael.

I get 404 on (for example) http://homeonthewater.com/js/main.js Please confirm that /var/www/html/js/main.js exists.... Michael.

Hmm... closer I think.. Try: a2enmod proxy_http a2enmod proxy_html ..and then restart Apache...

You shouldn't need any rewrite rule... 500 is a very generic 'something failed badly' message. Can I confirm that 192.168.0.171 is the IP address of your ISY - that it's HTTP port is 80 and that your 'Authorization' line in the virtual server config file contains the ISY username and password? Can I also confirm that the /etc/htpasswd-isy is the file that contains your 'mark/mark' credential - and that your .htaccess is referencing this same file? If could be that something has changed with Apache 2.4 that I'm not seeing on 2.2..... Can we try adding in the related ProxyPassReverse lines to see if they are needed now? ProxyPass "/rest/subscribe" "ws://192.168.0.171/rest/subscribe" retry=4 ProxyPassReverse "/rest/subscribe" "ws://192.168.0.171/rest/subscribe" retry=4 ProxyPass "/rest" "http://192.168.0.171/rest" ProxyPassReverse "/rest" "http://192.168.0.171/rest" ProxyPass "/services" "http://192.168.0.171/services" ProxyPassReverse "/services" "http://192.168.0.171/services" ProxyPass "/WEB" "http://192.168.0.171/WEB" ProxyPassReverse "/WEB" "http://192.168.0.171/WEB" ProxyPass "/USER" "http://192.168.0.171/USER" ProxyPassReverse "/USER" "http://192.168.0.171/USER" Michael.

Maybe the newer Apache is needing the ProxyPass attributes to be in quotes (mine does not care)... since only the quoted ones are working.... Try replacing: ProxyPass /rest http://192.168.0.171/rest ProxyPass /services http://192.168.0.171/services ProxyPass /WEB http://192.168.0.171/WEB ProxyPass /USER http://192.168.0.171/USER with ProxyPass "/rest" "http://192.168.0.171/rest" ProxyPass "/services" "http://192.168.0.171/services" ProxyPass "/WEB" "http://192.168.0.171/WEB" ProxyPass "/USER" "http://192.168.0.171/USER"

I also noticed http://homeonthewater.com/WEB/udajax.htm is not bringing up udajax either.... likely a type on the ProxyPass lines somewhere.... Michael.

Nice! So - sockets connect - but other rest calls fail. Interesting... Can you repost the file? (make sure to obfuscate the Authorization header!) Michael.

Nice! If the proxy lines are in there - http://homeonthewater.com/WEB/udajax.htm should open UDajax. If not - we need to dig into the proxy lines. Michael.

Interesting - this passes on my Apache. Just remove the line - it's likely not needed. Michael.

So - Apache is failing to start with the new config in place. You'll need to figure our why - something is missing.... With the new config (the one that fails) - what does: apachectl configtest reveal? Also - anything in /var/log/syslog when you try to start Apache with the new config ? Michael.

Can you send me what your virtual host config was before? (You said that you had backed up the original). Basically, someone is throwing an error, causing Apache to fail completely. You'll need to find out why that's happening from the logs. Michael.

I also note that http://www.homeonthewater.com/ redirects to http://homeonthewater.com/ - but they resolve to different IP addresses. Is this expected? Michael.

If you're getting 'Connection Reset' to which URL? As an FYI - if the authorization line isn't correct - you will get double prompted for credentials. Since this isn't happening here - this isn't the (immediate) problem. If it's one that doesn't match the ProxyPass lines - it probably means there is a syntax error and Apache isn't listening on the port. Anything is the error files? What happens if you restart Apache - any errors? Michael.

Make sure you've removed the 'ServerName' line! I believe you're not doing name based virtual servers - and this may be messing things up. Apache is doing 'pre-auth' - separately authenticating you. This allows you to use a separate credential for your published site. However, in order to present the correct credential to the ISY - ISYs username and password are needed. That's what the header insertion is doing for you. Michael.

The 'Authorization' string shouldn't be simply the ISY username OR password. It's needed in a standardized 'Authorization' format ("username:password" then base64 encoded). See https://en.wikipedia.org/wiki/Basic_access_authentication Client side[edit] When the user agent wants to send the server authentication credentials it may use the Authorization field. The Authorization field is constructed as follows: The username and password are combined with a single colon. The resulting string is encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line. The authorization method and a space i.e. "Basic " is then put before the encoded string. For example, if the user agent uses Aladdin as the username and OpenSesame as the password then the field is formed as follows: Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

Another thing to consider. If you are not using name based virtual hosts - please remove the 'Servername' line! You are issuing a redirect from 'www.homeonthewater.com' to 'homeonthewater.com' - but the 'ServerName' function will cause this configuration to be ignored - because the hostname does not match. Removing the 'Servername' line will allow the virtual to be used for all hostnames... Michael.

Also - have you created /etc/htpasswd-isy? Use: htpasswd -c /etc/htpasswd-isy user ..then set the password to protect your site... (change 'user' to your desired username).