User Level Access Control

Posted on
Mon Nov 19, 2012 4:59 pm
User187 offline
Posts: 20
Joined: Aug 17, 2010
Location: Scottsdale, Arizona

User Level Access Control

Based on my searches I have NOT seen this answered anywhere, but I would like to know what (if anything) is in the works to implement user level access into Indigo. We have 10 iOS deices that roam around the house and it would be great to let the kids have limited access to their own rooms and such without giving them the tools to terrorize the entire place.
Last edited by User187 on Mon Nov 19, 2012 5:23 pm, edited 1 time in total.

Posted on
Mon Nov 19, 2012 5:07 pm
nsheldon offline
Posts: 1812
Joined: Aug 09, 2010
Location: CA

Re: User Level Access Control

Unfortunately, this isn't yet possible, AFAIK. I'd like to have that feature too.

Posted on
Mon Nov 19, 2012 6:14 pm
nsheldon offline
Posts: 1812
Joined: Aug 09, 2010
Location: CA

Re: User Level Access Control

One option I just thought of (but haven't tried myself yet) might be to create a web page served by the Mac's built-in Apache server where the images (or links) on the page execute CGIs or other shell command to tell Indigo to do things. Unfortunately, you're likely to encounter difficulties due to OS X's sandboxing and permissions security measures. It may require you to do some "creative" workarounds that involve "sodu" and the "expect" command. :)

Posted on
Mon Nov 19, 2012 6:45 pm
matt (support) offline
Site Admin
User avatar
Posts: 17658
Joined: Jan 27, 2003
Location: Texas

Re: User Level Access Control

Correct, there is currently no user level access settings for Indigo Touch -- just a single user with all access. As mentioned above, if you know how to configure Apache then you might be able to hack together something. Adding more access control functionality is on our list of features we would like to eventually see in Indigo Touch (and the Indigo Web Server).

Image

Posted on
Tue Nov 20, 2012 9:48 am
User187 offline
Posts: 20
Joined: Aug 17, 2010
Location: Scottsdale, Arizona

Re: User Level Access Control

nsheldon wrote:
One option I just thought of (but haven't tried myself yet) might be to create a web page served by the Mac's built-in Apache server where the images (or links) on the page execute CGIs or other shell command to tell Indigo to do things. Unfortunately, you're likely to encounter difficulties due to OS X's sandboxing and permissions security measures. It may require you to do some "creative" workarounds that involve "sodu" and the "expect" command. :)


Never though of that. However, sounds like it could be a task Im not willing to do just to let the kids control their own lights and AV equipment! :)

Posted on
Tue Nov 20, 2012 9:54 am
User187 offline
Posts: 20
Joined: Aug 17, 2010
Location: Scottsdale, Arizona

Re: User Level Access Control

matt (support) wrote:
Correct, there is currently no user level access settings for Indigo Touch -- just a single user with all access. As mentioned above, if you know how to configure Apache then you might be able to hack together something. Adding more access control functionality is on our list of features we would like to eventually see in Indigo Touch (and the Indigo Web Server).


I think many Indigo users would agree that user level access would be an invaluable feature, especially for Indigo Touch. I actually posted this same question long ago (Ver. 4'ish if I am not mistaken) and have been waiting patiently for it to be implemented! :)

Posted on
Tue Nov 20, 2012 10:45 am
nsheldon offline
Posts: 1812
Joined: Aug 09, 2010
Location: CA

Re: User Level Access Control

Matt: Not being very familiar with the IWS plugin architecture, would it be possible for someone to create an IWS plugin that overrides the current authentication mechanism and presents a different one (or, rather, the same type of authentication mechanism with a different authentication source) to the web client?

Posted on
Tue Nov 20, 2012 11:28 am
durosity offline
User avatar
Posts: 2932
Joined: May 10, 2012
Location: Newcastle Upon Tyne, Ye Ol' England.

Re: User Level Access Control

Could this not be done by creating a separate control page with the modules you want them to control, opening it in safari then bookmarking it (then remove the indigo touch app)?

Computer says no.

Posted on
Tue Nov 20, 2012 11:30 am
matt (support) offline
Site Admin
User avatar
Posts: 17658
Joined: Jan 27, 2003
Location: Texas

Re: User Level Access Control

durosity wrote:
Could this not be done by creating a separate control page with the modules you want them to control, opening it in safari then bookmarking it (then remove the indigo touch app)?

The user could edit the URL though to go back to the main Indigo page with access to all the Devices, Control Pages, etc.

Image

Posted on
Tue Nov 20, 2012 11:31 am
matt (support) offline
Site Admin
User avatar
Posts: 17658
Joined: Jan 27, 2003
Location: Texas

Re: User Level Access Control

nsheldon wrote:
Matt: Not being very familiar with the IWS plugin architecture, would it be possible for someone to create an IWS plugin that overrides the current authentication mechanism and presents a different one (or, rather, the same type of authentication mechanism with a different authentication source) to the web client?

The IWS plugins don't provide that level of overriding, unfortunately.

Image

Posted on
Wed Nov 21, 2012 3:07 pm
nsheldon offline
Posts: 1812
Joined: Aug 09, 2010
Location: CA

Re: User Level Access Control

As a proof of concept (and because I've been wanting to test this myself anyway), here's some PHP code that you can save into the Mac's built-in web server documents directory at /Library/WebServer/Documents which will accept basic HTTP GET requests (ones that you can just type into your browser's address bar or assign to a link in another web page) and turn on or off a device or set it's brightness level without requiring the web page viewer to authenticate.

Code: Select all
<html><?PHP
/* =========================================================
Indigo Control Proxy

Version 1.0 b1
by Nathan Sheldon
nathan@nathansheldon.com

This script accepts HTTP GET requests containing a device
    name, device state, and value for that state.  It then
   attempts to set the device's state to the specified
   value.  Currently, only the "brightness" and "on" states
   are recognized.  Also, this script does little more than
   check to see if a device, state, and value were submitted
   and does not check if the information makes sense.
   
Use at your own risk!

========================================================= */

// ==== EDIT THESE VARIABLES ====

// The username and password below should be set to the username
//    and password of the local administrator account under which
//    the Indigo server is launched, otherwise this proxy will
//    fail.  Note that you can't use quotes in your username or
//    password.  Other special characters may also cause errors.

$username      = "myUsername";
$password      = "myPassword";



// ==== DON'T EDIT ANYTHING AFTER THIS LINE ====


// Set error reporting level to avoid warning messages.
error_reporting (E_ERROR);

// ==== DEFINE VARIABLES ====

$device         = $_GET['device'];   // Indigo device name to control.
$state         = $_GET['state'];   // Device state to change. Currently,
                           //   only "brightness" and "on"
                           //   are controllable.
$value         = $_GET['value'];   // Value to change the device state to.


// ==== DEFINE FUNCTIONS ====

function fExecuteAppleScript ($AS) {
/* ----------
   Expects:
      $AS         :   string with AppleScript to execute.
      
   Returns:
      $Response   :   string with result of expect and su command.
---------- */
   
   global $username, $password;
   
   // Properly escape characters for use in shell + expect + shell command.
   $AS            = str_replace ('"', '\\"', $AS);      // Escape quotes because we're in a shell
   $AS            = str_replace ("\\", "\\\\\\", $AS);   // Escape escapes an additional 3 times.
   $AS            = str_replace ("\t", "", $AS);         // Remove tabs.
   $AS            = str_replace ("\n", "\\\r ", $AS);      // Convert newlines to tripple-escaped returns with a tailing space.
   
   $Command      = "expect -c \"spawn su - ".$username."; expect -re \\\".*assword.*\\\"; send \\\"" .$password."\\r\\\"; expect \\\"\\\\\\\\$\\\"; send \\\"osascript -e \'".$AS."\'\\r\\\"; expect \\\"\\\\\\\\$\\\"; send \\\"exit\\r\\\"; expect \\\"logout\\\";\"";
   
   print "<!-- Command: ".$Command." -->\n";
   
   $Response = shell_exec ($Command);
   
   error_log ("IWS Control Proxy response: ".$Response);
   
   return $Response;
} // End fExecuteAppleScript function.


// ==== START HTML CONTENT OUTPUT ====

?><head><title>Indigo Control Proxy</title>
<?

// ==== VALIDATE SUBMITTED DATA ====

// Limit access to 192.168.1.xxx address range based on REMOTE_ADDR value.
if (!preg_match ("/192\.168\.1\.[0-9]{3}/", $_SERVER['REMOTE_ADDR'])) {
   
   print "</head>\n";
   print "<body>\n";
   print "Access denied for your IP address (".$_SERVER['REMOTE_ADDR'].").\n";
   
} elseif (($state == "brightness" or $state == "on") and
         $device != "" and
         $value != "") {

   print "<!-- Setting ".$device." ".$state." to ".$value.". -->\n";
   
   // ==== CREATE THE APPLESCRIPT ====
   
   $AppleScript = "tell application \"IndigoServer\"\n";
   if ($state == "brightness") {
      $AppleScript = $AppleScript.'    set brightness of device "'.$device.'" to '.$value."\n";
   } elseif ($state == "on") {
      if ($value == "true" or $value == "on") {
         $AppleScript = $AppleScript.'    turn on device "'.$device."\"\n";
      } elseif ($value == "false" or $value == "off") {
         $AppleScript = $AppleScript.'    turn off device "'.$device."\"\n";
      }
   }
   $AppleScript = $AppleScript.'end tell';
   
   print "<!-- HTTP Referer: ".$_SERVER['HTTP_REFERER']." -->\n";
   print "<!-- AppleScript to execute:\n".$AppleScript."\n-->\n";
   
   // ==== EXECUTE THE APPLESCRIPT ====
   
   $scriptResponse = fExecuteAppleScript ($AppleScript);
   
   error_log ($scriptResponse);
   print "<!-- Response:\n".$scriptResponse."\n-->\n\n";
   
   // ==== REDIRECT THE USER TO THE PAGE THAT THEY CAME FROM ====
   
   if ($_SERVER['HTTP_REFERER'] != "") {
      print "<meta http-equiv=\"refresh\" content=\"0;URL='".$_SERVER['HTTP_REFERER']."'\">\n";
      print "</head>\n";
   } else {
      ?></head> <?
   }
   ?><body>
   <?
   print "Command sent.\n";
   
} else {
   
   print "</head>\n";
   print "<body>\n";
   print "Invalid input.\n";
   
}

// ==== END HTML OUTPUT AND SCRIPT ====

?>
</body>
</html>

To install it...

  1. Copy the code above into a text editor like TextEdit. Replace the "myUsername" and "myPassword" values near the top of the script with the username and password of the Mac OS X administrator used to run Indigo on the machine.
  2. If your network uses a different IP address range than the most common "192.168.1.x" range, you'll need to modify the line that starts with
    Code: Select all
    if (!preg_match ("/192\.168\.1
    replacing the 192, 168, and 1 with your network's first 3 IP address numbers. This bit of code is included to help prevent people form outside your internal network from accessing the page and controlling your devices. The script will return an error if the requesting web client's IP address isn't from the IP range specified here.
  3. Save the file as plain text, with the name "indigo-control.php" (or any name you like that ends in .php). The file must be saved on the same machine running the Indigo server. Save the file either into the server's document root at /Library/WebServer/Documents or into the admin user's web site directory at /Users/<username>/Sites, where <username> is the admin user's short name. You may need to enter the administrator username and password to save it.
  4. Backup your Apache configuration file in /etc/apache2 by going to the "Go" menu in the Finder, selecting "Go to Folder...", typing "/etc/apache2" and clicking "Go". Then hold down the "option" key on your keyboard and drag the "httpd.conf" file to your Desktop to make a copy of it there.
  5. Using TextEdit, modify the "httpd.conf" Apache configuration file in the /etc/apache2 folder that's still open. Remove the "#" character at the beginning of the line that says
    Code: Select all
    #LoadModule php5_module libexec/apache2/libphp5.so
    Save the changes.
  6. Disable, then re-enable web sharing. In Mac OS X 10.7.x or earlier, this is done in the "Sharing" control pane in System Preferences. In Mac OS X 10.8 Mountain Lion, Apple removed the web sharing option to "encourage" users to buy the server version, but Apache is still installed and works. The easiest way to enable web sharing in Mountain Lion is to use the free 3rd party "Web Sharing in OS X Mountain Lion" control pane.

To use it...

  1. Open any web browser on a device connected to your internal network.
  2. Enter the URL http://<your-server's-ip>/indigo-control.php?device=<Some+Device+Name>&state=<"brightness" or "on">&value=<some-value> where <your-server's-ip> is the IP address of your Indigo server, <Some+Device+Name> is the exact name of any device in Indigo, including capitalization, replacing spaces with + symbols (special characters may cause problems and aren't recommended), <"brightness" or "on"> is the work brightness or the word on (depending on whether you want to control the brightness or on state of the device), and <value> is the brightness value or on state of the device. An example brightness control URL would be
    Code: Select all
    http://192.168.1.100/indigo-control.php?device=Family+Room+Lamp&state=brightness&value=80
    An example on/off control URL would be
    Code: Select all
    http://192.168.1.100/indigo-control.php?device=Family+Room+Lamp&state=on&value=false

Using the above URL creation method, you could create a basic web page with links or web forms that would control devices. The PHP page will automatically redirect the client browser to the referring URL whenever it processes a request.

Posted on
Mon Feb 27, 2017 11:06 am
spiv offline
Posts: 114
Joined: Jul 15, 2014

Re: User Level Access Control

Time to "ping" this important feature request:

Since at least 2012, many people have been requesting the ability to have "guest" and/or multi-user login capability for Control Pages and Indigo Touch.

This is not cosmetic or nice-to-have, it has become a "must have" capability that is holding back wider deployment/use of Indigo.

Hacking reverse proxy web servers or building a custom UI using REST API is beyond many people's technical chops, but more importantly, it is a terrible use of our time and effort.

With the release of Indigo 7 ("The big Z-Wave release") completed, it is time for a lot of these crucial, but deferred, requests to be addressed.

Matt & company, can you give us general visibility into whether you are even considering any of this requests that "have been under consideration" since 2012 or earlier will be addressed?

Maybe a new subforum to collect/sort/discuss enhancements/feature requests specifically for post Indigo 7 releases? (There are a lot of ideas and feedback scattered throughout all the forums. I tried searching/reading to pick the "best" place to re-start this thread, for example.)

Posted on
Mon Feb 27, 2017 11:28 am
matt (support) offline
Site Admin
User avatar
Posts: 17658
Joined: Jan 27, 2003
Location: Texas

Re: User Level Access Control

We won't be providing any updates or scheduling details for when major new functionality will be implemented. We are hard at work on new functionality though, and you are correct that Indigo does need more access control options.

Image

Posted on
Sun Jul 23, 2017 6:31 pm
agame offline
Posts: 49
Joined: Jul 13, 2017

Re: User Level Access Control

As a new Indigo user (migrating from Vera), I'd like to add a vote for this feature.

Its one of the few areas that indigo benchmarks poorly compared to the vera platform. There are a few use cases that I personally would want it for:

- allowing me to provide access to indigo for house sitters, and then revoke access without major effort (better still by creating a simplified 'guest view' with essential functionality like HVAC control).
- limiting functionality available to a wall-mounted iPad (e.g. don't want to present an intruder the ability to disarm alarm without a code).
- being able to identify which user performed an action (e.g. arm/disarm alarm) would also be useful.

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 4 guests