-
Posts
4959 -
Joined
-
Last visited
Everything posted by MWareman
-
I think one of the older io_guy programs supported subscribing to the ISY and logging locally (isy_logger ?). This needs an always on computer though (like a RaspberryPI) - and the newer versions are being built as a node server (requires PRO and the network module).
-
That, is *very* cool! Mark, I *really* hope you are able to share more of what you are doing here. There are some extremely useful elements that absolutely should be put into a new HTML5 admin interface.... this being one of them (for Elk module owners!)
-
Also, prefix it with ~ and it will be suppressed from the web interface.
-
You can create web pages on the go with any number of devices...... For the ISY to perform certain functions (such as making API and other network calls), the optional module is needed that is not included in the base device, because not everyone has need for it. This is a way the initial cost of the device is kept down, and people that don't need it are not paying for it. You can either buy the networking module, or subscribe to the ISY Portal (which includes use rights to the module, and so much more!). IMO - it was the best $50 I ever spent. I do *so much* with it. Just look at the Network Resources page on the Wiki to get a taste of the possibilities.
-
If you have an Elk panel, use a zone as an entry zone (wiring it to the mag sensor), and use the output to trigger the door. This is what I do. It's been absolutely flawless. Thru the Elk module, you can still control! The door, and get status.
- 44 replies
-
- ISY
- Power Failure
-
(and 2 more)
Tagged with:
-
I don't use Locative (I'm an Android user), but I believe it can call any url. As such, get the IFTTT URL (the one you normally plug into the Maker channel to trigger the action) and plumb that directly into Locative. It should work. Hopefully, Locative supports a POST though, as that's required I believe. Michael.
-
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.