Teken Posted August 11, 2015 Share Posted August 11, 2015 Remember we are east of you and will have this installed before you even get out of bed! :) LOL . . . You always make my day. Link to comment
giesen Posted August 11, 2015 Share Posted August 11, 2015 giesen, 3-4 seconds for 2048 bit. Going to Paypal takes longer than 3-4 seconds. With kind regards, Michel Michel, The problem is I might run eKeypad, wait 4 seconds, then switch to another app, do something, then switch back and I have to wait another 4 seconds. Or the screen on my phone times out then I have to wait 4 seconds again. Not a great user experience. Now the blame is not entirely on UDI, since eKeypad doesn't support session persistence, but the result is the same. Is 5.0 expected to have a new API that is proxyable? Link to comment
MFBra Posted August 12, 2015 Share Posted August 12, 2015 Unless the ISY is hundreds of miles away!But it will only happen if you forgot your own password or if you are under attack... MFBra Link to comment
giesen Posted August 12, 2015 Share Posted August 12, 2015 Interesting comments, thanks. As a novice pi user, what are the precautions needed to protect the pi from the internet? Limit access to specific ports via firewall?Yes, that and implementing something like fail2ban which watches your log files and will block any IPs that unsuccessfully attempt to authenticate a number of times. And change your default passwords. Link to comment
MFBra Posted August 12, 2015 Share Posted August 12, 2015 I'll try to summarize my suggestion, but I'd like to see 1) multiple users, providing distinct access levels, I mean, - admin or full access - user access - let you turn on/off devices or programs but not add devices or programs, etc - interface - for rest connections with limited access. And you may restrict the source ip. - not sure where should allocate mobilinc access (for instance) 2) timeout configuration for wrong password, notifications would be great also. 3) for the highest level of users, possibility to adopt OTP (on time password) such the Google authentication, Dropbox for instance let you utilize googles software to generate the OTP. In this scenario, you keep REST, do not loose mobilinc access and increase the protection. Knowing that security does not get along with simplicity ..... MF_Bra Link to comment
MWareman Posted August 12, 2015 Share Posted August 12, 2015 Yes, that and implementing something like fail2ban which watches your log files and will block any IPs that unsuccessfully attempt to authenticate a number of times. And change your default passwords.I run an Asterisk PBX at home - and I used to get brute force attacks against the SIP stack weekly. I've had enormous success using fail2ban to shut this stuff down pronto. Make sure you whitelist your own machines though! Link to comment
MWareman Posted August 12, 2015 Share Posted August 12, 2015 Google's authentication is relatively trivial to implement in a disconnected system - I've done it myself in tcl (F5 iRule). The only impediment would be allowing products like Mobilinc to continue connecting. Separate accounts would be one answer - but API keys would be FANTASTIC for things like the IFTTT Maker channel so we don't have to give away privileged credentials or deal with authorization headers at all. Link to comment
MFBra Posted August 12, 2015 Share Posted August 12, 2015 Google's authentication is relatively trivial to implement in a disconnected system - I've done it myself in tcl (F5 iRule). The only impediment would be allowing products like Mobilinc to continue connecting. Separate accounts would be one answer - but API keys would be FANTASTIC for things like the IFTTT Maker channel so we don't have to give away privileged credentials or deal with authorization headers at all. Yes, but been easy to implement, why not consider one "seed" of the OTP inside mobilinc also? It could send the fixed password and also the OTP. If someone sniffs that traffic should hijack your connection only during that session... Hardware to decrypt the https in a correct time-frame to still have the session open. If someone implement this to target someone ISY, should be a POVHI "person of VERY HIGH INTEREST", and in that case, nothing will really protect you... MF_Bra Link to comment
Michel Kohanim Posted August 12, 2015 Share Posted August 12, 2015 Hi giesen, Michel, Is 5.0 expected to have a new API that is proxyable? It should be proxyable now ... I think MWareman uses it. With kind regards,Michel Link to comment
MWareman Posted August 12, 2015 Share Posted August 12, 2015 I currently proxy access to the REST and SOAP interfaces, and this works well. However, SOAP subscriptions fail due to the nature of the protocol. This means the admin console and apps like Mobilinc don't work well at all thru the proxy. Finally, I don't yet have websocket subscriptions working thru the proxy, but that's due to lack of time... I know its possible. Link to comment
Michel Kohanim Posted August 12, 2015 Share Posted August 12, 2015 Hi MWareman, thanks so very much for the details. Do you know why subscriptions do not work? With kind regards, Michel Link to comment
MWareman Posted August 12, 2015 Share Posted August 12, 2015 For the SOAP ones, its because the ISY opens a socket back to the caller - and when you come thru a proxy the caller appears to be the proxy itself. So the callback never makes it to the client. Even if it did work - it would make the point of an SSL proxy somewhat redundant. For webservices, there is a proxy module I need to install to handle webservices. I just have not installed and configured it (yet). I know io_guy has now converted all of his apps over to the websocket interface. Has the admin console moved yet? Or is this still using the older subscription method? If the latter - are there plans to change - or are you still waiting for a half decent websocket library for Java that supports basic authentication? Link to comment
Michel Kohanim Posted August 14, 2015 Share Posted August 14, 2015 Hi MWareman Thank you. No Admin Console has not moved to Websockets and I doubt it would as we are preparing (or hoping) to migrate to HTML5 and it would be a waste. I just wished we had more resources to make this move a little quicker. I think if clients such as ekeypad move to Websockets it would make life much easier for us all. With kind regards, Michel Link to comment
MWareman Posted August 14, 2015 Share Posted August 14, 2015 Hi MWareman Thank you. No Admin Console has not moved to Websockets and I doubt it would as we are preparing (or hoping) to migrate to HTML5 and it would be a waste. I just wished we had more resources to make this move a little quicker. I think if clients such as ekeypad move to Websockets it would make life much easier for us all. With kind regards, Michel Agreed! I do agree with your direction - an HTML5 admin UI is *definitely* the way to go! Link to comment
Teken Posted August 14, 2015 Share Posted August 14, 2015 Agreed! I do agree with your direction - an HTML5 admin UI is *definitely* the way to go! I gather from this statement all of use could look forward to retiring the Java interface? If so, please consider incorporating this feature in the Kick Starter campaign. For that virtual node project, to help finance and provide a seat for a contract developer. Link to comment
Michel Kohanim Posted August 14, 2015 Share Posted August 14, 2015 Hi Teken, Will surely consider. Thank you. With kind regards, Michel Link to comment
giesen Posted August 15, 2015 Share Posted August 15, 2015 Perhaps the release of 5.0 might be a good milestone to deprecate (at least officially) the SOAP API and encourage developers to move to websockets? Link to comment
Michel Kohanim Posted August 18, 2015 Share Posted August 18, 2015 Hi giesen, Deprecation is a good idea but we still need to keep those around simply because we do not want to cause any interruptions. With kind regards, Michel Link to comment
giesen Posted August 18, 2015 Share Posted August 18, 2015 Yeah I didn't mean actually pull the API, but publish a notice in the release notes that's it has been deprecated and will be removed at some point in the future. Developers will have time to move their apps to the new APIs and new developers hopefully won't write something new using the deprecated API Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.