[SM-PLUGINS] ACL for plugins

[Brad D. <buc...@us...>]

Hi folx,

I had asked about the ability to turn on certain Extra plugins for a given set
of users a little while back. SM doesn't support this out of the box, but I am
wondering if we can work toward that end??? Perhaps it can be something as
simple as an include_once near the beginning of the
squirrelmail_plugin_init_useracl call of any plugin. The functionality could
even be included in that call, but that would be unnecessary and extra
overhead to have there for plugins and sites that don't make use of it...

Here's a couple thawtes on a way to add this functionality to a plugin:

1:
* Add a function, perhaps to functions/acl.php (though I'm sure there is a
better place for this), called group_access that takes an array of strings as
a parameter. Those strings would represent text files in the config directory
which simply list account names, one per line, that have extra access to any
plugins that refer to those files.

* Then inside a plugins setup.php you might see something like:
function squirrelmail_plugin_init_myplugin() {
  global $plugins, $squirrelmail_plugin_hooks;

// use new function to determine if this plugin should be active
// for the current username.
  include_once(SM_PATH . 'functions/acl.php');
  if (group_access(array('staff'))) {
// now we know it's OK to install this plugin
    $squirrelmail_plugin_hooks['menuline']['myplugin'] = 'myplugin_menu';
  }
}

* The config directory, in this example, would then have a flat file called
"staff", and it would be filled with accounts that have access to "myplugin".

The end result is that you can install plugins that offer something extra for
a specified set of customers. Any normal plugins would be seen as usual, so I
guess my method is sort of reversed. Everyone sees all unmodified plugins. Any
plugins that have their plugin_init modified as above are now restricted to
those users listed in the config/staff file.

2:
* Another way may be to add an optional parameter to the
squirrelmail_plugin_init call, which would be the same array of strings. The
init code would check to see if there's a parameter and if it was a readable
file found in the config directory. It could assume that everyone has access
to this plugin if there is no parameter or if the one supplied is unreadable.

* The init code would then open the file(s) to check if the current $username
has access to this plugin. If so then it would continue with hook
registration, otherwise it would silently return without the plugin in
question having registered itself with any hooks.

Now perhaps there would also be a way to make this idea more granular. The
hook registration could be were the access checks are being made. So a plugin
could have some hooks registered to ALL users and a few hooks are registered
only for the specified groups of users? Don't know if I'd use that, but
perhaps there would be some use for this?

I have worked out the code for idea #1 above. It suites my current purposes,
but perhaps this idea would look good in the SM code base as well? Any
thoughts or comments on this??? Is this idea worth pursuing for SM in general?

Brad
--
Last time I had this much fun was, ... uh ...