elionce

Huh? You mean the ISY-994i is an old/deprecated controller, and there's a newer / full replacement for it for which the API does have proper access control...? Completely false. The ISY is a network-connected device, on the internet, controlled by online devices. Insteon is a short-range local interface where you need physical access to a device before you can pair it with a controller. These are not even remotely the same topic. Saying "there's no point in being able to limit access privileges on a online API, because someone could physically go and unscrew the light switches from the wall and relink them to a new controller" - I don't even know where to begin. Anyway, this has gone way off the rails and needn't be discussed any further. I have my answer, and it's clear enough: the ISY runs a REST api where the only way to connect to it is by sending full administrative credentials with every command. There are no credentials that I could tell any user that would enable them any access other than "administrative."

You keep sharing how your system is setup - that's great, but as stated previously, yours clearly isn't the same as everyone's. I understand that I can invest time & energy in installing a bunch of extra keypanels all over the place to (partially) workaround the lack of user access control. ....And still leave the root credentials "remembered" on everyone's mobile devices for when they aren't home ....And continue sending those full administrative credentials over the internet with every command ....Including if a family member unknowingly ends up using their phone on an unknown/untrusted network ...And continue having to personally setup everyone's client for them, rather than simply being able to say "visit this URL & enter this user/pass"

I'm not, & that sounds like an awful lot of work. Which to me that just serves as evidence that proper user credentials *is* something people actually want/need.

Right, of course it would have to be built (aka would have to be implemented by the developers of the ISY). I was merely responding to simplextech's statement that it's "an embedded system and is not going to have multi-user capabilities today with the OS and hardware it runs on." The hardware, and the fact that it's embedded, is not a limiting factor. The only limiting factor is the fact that the firmware has just not been implemented in a way that takes access control into consideration. ...No - again, access control is a server-side issue, not a client-side one. Whether you use the Admin Console or web access (or rest api or mobile app) is irrelevant to the issue I'm describing; you're still always communicating with the ISY via the same admin credentials, which have full permission to do everything. There is no credential I can give someone that will let them only work with the web UI, but not the admin console. Right. Thus, the conclusion was: the ISY simply cannot do it (as it's currently been implemented) :P

>>Most other Linux distros don't come with sudo pre-configured and do require you to login as root and then you can decide if you want to configure sudo or not. Well, or you login as a standard user and su (rather than sudo) when you need to perform administrative actions. Perhaps a better analogy might be my NAS. When the media players login to its media shares to access media, they don't do so with full administrative privileges. When backup software logs into a backup share to upload data to it, it doesn't send full administrative credentials over the wire. Only when actually performing administrative tasks will one login as admin. Same is true for my security camera controller, database server, and so on. Indeed there is exactly one device I have running where every client is always admin - and you can probably guess which that is >>There's improvements and changes coming. Fingers crossed! ? >>That's the whole basis of Polisy afterall. I wasn't aware of Polisy. Seems like this additional device is aimed at providing a different set of integrations than I actually need though. The existing ISY's functionality is already fantastic - it's just the inability to use it in a security-conscious way that's a bit troubling. >>The ISY is an embedded system and is not going to have multi-user capabilities today with the OS and hardware it runs on I hear that the answer is "no it's not available," but just to respond to this, checking user permissions is almost certainly not limited by hardware or by virtue of it being an embedded system. If the hardware can validate one set of user credentials, I can't think of any reason it'd be unable to validate against a few. It's really just a matter of it not having been coded (yet, hopefully).

>>yeah any interface currently would need the credentials to interface with the REST interface. That's just the way it is today. There's been talks about improving that. It would be nice to move to a token based setup for interface access. I agree tokens would be more ideal. But at the very least, if credentials are going to be sent, it should be possible to not have to send the *admin* credentials. 95% of usage is just controlling devices, not actually modifying programs or reconfiguring - so there's no reason to be giving that level of access to every endpoint. Analogy: when working on a Linux machine, do you login as root & do every action as root? Of course not - you just sudo the few commands that might actually require it, & the rest of your work uses a regular limited-access user account. And that's just on a local machine. Here we've got a networked device that effectively requires you to use root for everything. Every client, every command, any access at all, is done as root. Even remote ones executed over the internet. >>For the first part. What web UI are you referring to or is this just in general? In general.

Guests do *NOT* need admin access - that's the issue. The only access that can be given currently is admin, to everyone, on all devices. So if I want to i.e. give someone a way to easily turn something on or off via the web UI...it can't be done. Either I give them the administrative login, or nothing. Plus the other security-related issues mentioned above (storing full admin credentials on devices unnecessarily, sending full admin credentials over the wire unnecessarily, etc).

I don't doubt that scenarios could exist where proper user credentials aren't necessary. I guess yours is one such scenario. Mine is not.

Bummer. Just curious if there are any plans to rectify this? Frankly I'm a bit shocked that this doesn't come up more often - I can't really think of any online/remote system I've ever worked with where the sole way to interact with it is with full administrative credentials. It feels so nuclear to say either "give access to every single function with no limitations," or "can't use it at all."

That would still be limitations placed by the client application, which doesn't really address the issues mentioned above. Every device is still storing the full administrative credentials, sending the full administrative credentials over the wire with every command, etc. If a guest comes over & wants to be able to flip some devices on or off from the web UI, they still need to be told the full administrative credentials. I don't really see how a limitation placed by Mobilinc or Agave would address any of this...?

I'm not referring to logging into the full admin console as non-admin. Just to do basic device control (i.e. from Agave app on Android, from the web UI in browsers, from the rest API, etc).

How can I login to the ISY as a non-admin user account? I've searched high and low, but couldn't seem to figure it out. There are quite a few obvious issues with just always logging in as admin (i.e. it's unnecessary to have full administrative privileges just to perform simple device control; I have to give all family members and/or guests the admin credentials even if they're computer illiterate / don't know how to use password managers; having everyone always login as admin leads to using a less complex password than if I were the only one using it; leaving the admin credentials "remembered" on mobile devices could potentially be a security issue if the device gets lost; logging in as admin from unknown/untrusted networks could potentially be an unnecessary security risk; etc, etc, etc). I can't recall if I asked this somewhere before, but couldn't find it, so apologies if it's a repeat

Cool, thanks for the feedback. That's pretty much what I thought, but just wanted to make sure I wasn't overlooking something obvious (i.e. maybe an actual built-in way to have it confirm status before proceeding, etc) :)

I'm using my ISY as a controller for my sprinklers (via EZFlora/EZRain). I've been having some issues where sometimes (but very rarely) the EZFlora doesn't receive an on/off command, which may leave one of the sprinkler lines running (if it was a missed OFF), or skip one of the lines (if it was a missed ON). I've tried replacing the EZRain itself, as well as installing more dual-band devices as close to the EZRain as possible in hopes of "boosting" signal redundancy - but presumably due to its distance in the back yard, I can't seem to get it totally 100% reliable. For instance, if I just try to toggle one of the lines off & on repeatedly, it may work 30 times in a row, but then the 31st it won't, and if I have the ISY java panel up, it'll show an "error communicating" dialog. Then if I try once more, it works & the java panel shows that it's again connected. Currently, my sprinkler programs are just: Send on command wait x minutes Send off command I'd thought about adding some redundancy by doing something simple like Send on command Wait 5 seconds Send on command again Wait x minutes Send off command Wait 5 seconds Send off command again ...So that each on or off command would be sent twice, in case there's a communication error - but before I do so, was wondering if there might be a more elegant or suggested way to i.e. have the program actually check if the command worked, and retry if it didn't (rather than just brute-force doubling up each command). Or would this simple double-command approach be a good way to hopefully resolve those few 'missed command' situations? Thanks in advance!

Bummer they're so flaky. I actually didn't even realize they have a "low battery" signal - I just figured a program would be handy to say "it's no longer working," rather than having to *ever* walk around & check everything, or change it prematurely. But...maybe just using motion sensing event in addition to Dusk.Dawn will make the difference. Or maybe I could increase the time threshold to 48 hours before it notifies. Time will tell, the new experiment starts now