Khaos :: KhACL

[eluser]adamp1[/eluser]
Oh yes, I got my DELETE and SELECT mixed up.

[eluser]lightnb[/eluser]
Hi all,

So I'm trying to figure out how this works in the real world, and I'm a bit confused.

Let's say I have a site with a forum and an article publishing system, and a single user/login system for both.

I would create users like this?:

Code:

/* Setup Users
************************/

// Add Superman and Wonderwoman to the "Administrators" group
$this->khacl->aro->create('Superman', 'Administrators');
$this->khacl->aro->create('WonderWoman', 'Administrators');

// Add Bob and Joe to the "Moderators" group
$this->khacl->aro->create('Bob', 'Moderators');
$this->khacl->aro->create('Joe', 'Moderators');

// Add Tom and Steve to the "Publishers" group
$this->khacl->aro->create('Tom', 'Publisher');
$this->khacl->aro->create('Steve', 'Publisher');

// Create a "Public" user that will be used for unregistered site users...
$this->khacl->aro->create('PublicUser', 'PublicGroup');

And then create a list of actions:

Code:

/* Define actions that site users might perform
****************************************************/

// Actions for the forums
$this->khacl->axo->create('DeleteOwnForumPosts');
$this->khacl->axo->create('DeleteOthersForumPosts');
$this->khacl->axo->create('EditOwnForumPosts');
$this->khacl->axo->create('EditOthersForumPosts');

// Actions for Article Publishing
$this->khacl->axo->create('PublishArticles');
$this->khacl->axo->create('ReadArticles');
$this->khacl->axo->create('CommentOnArticles');

And then Assign users and groups to actions:

Code:

/* Assign permissions to users and groups
****************************************************/

// "Administrators" can perform every action
$this->khacl->allow('Administrators', 'DeleteOwnForumPosts');
$this->khacl->allow('Administrators', 'DeleteOthersForumPosts');
$this->khacl->allow('Administrators', 'EditOwnForumPosts');
$this->khacl->allow('Administrators', 'EditOthersForumPosts');
$this->khacl->allow('Administrators', 'PublishArticles');
$this->khacl->allow('Administrators', 'ReadArticles');
$this->khacl->allow('Administrators', 'CommentOnArticles');

// except "WonderWoman". She can't delete other's posts
$this->khacl->allow('WonderWoman', 'DeleteOthersForumPosts'); // Can I do this to an individual user?

// Moderators can do everything except 'publish articles' and 'delete other's forum posts'
$this->khacl->allow('Moderators', 'DeleteOwnForumPosts');
$this->khacl->allow('Moderators', 'EditOwnForumPosts');
$this->khacl->allow('Moderators', 'EditOthersForumPosts');
$this->khacl->allow('Moderators', 'ReadArticles');
$this->khacl->allow('Moderators', 'CommentOnArticles');

// except "Bob" can 'delete other's posts', cus he's cool ;)
$this->khacl->allow('Bob', 'DeleteOthersForumPosts');

// Publishers can publish articles, and can also edit thier own posts
$this->khacl->allow('Publisher', 'EditOwnForumPosts');
$this->khacl->allow('Publisher', 'PublishArticles');
$this->khacl->allow('Publisher', 'ReadArticles');
$this->khacl->allow('Publisher', 'CommentOnArticles');

// All site users can read articles
$this->khacl->allow('PublicGroup', 'ReadArticles');

Are the above assumptions correct?

But what is the purpose of the ACO then? Would "Forums" and "Articles" be the ACOs?

Second, how would this apply to individual sections, such as forum categories? Let's say Bob can only Edit and Delete posts in the "Birds" Forum category, while "Joe" can only moderate the "Mammals" forum?

Third, how do IDs play into this? Do I just replace the groups and names in the above examples with their appropriate MySQL UIDs instead?

[eluser]adamp1[/eluser]

But what is the purpose of the ACO then? Would “Forums” and “Articles” be the ACOs?

ACO's are control objects, so basically they could be as you said forums and articles, or you could have control objects for each forum post/article. Depends how much control you want.

You can nest control objects, so say you have the following:

Code:

Site
| - Forum
    | - Birds
    | - Mammals
    ` - Other
` - Articles
    | - Category 1
    ` - Category 2

Second, how would this apply to individual sections, such as forum categories? Let’s say Bob can only Edit and Delete posts in the “Birds” Forum category, while “Joe” can only moderate the “Mammals” forum?

You can create a rule allow('Bob','Birds','Edit') & allow('Bob','Birds','Edit'), same goes for joe but with a different control object.

Third, how do IDs play into this? Do I just replace the groups and names in the above examples with their appropriate MySQL UIDs instead?

The names used are for your benefit, if you look in the database tables you can provide a 'link' ID, this means you don't need to go and play around with the table but can add all your custom fields in a new table but still link the records.

The actual way the system runs is very simple and easy to understand, what's hard is a way to manage it. This is what I'm currently doing for my administration system. I would go have a look maybe at my screenshots of my ACL administration system to get a feel of it. Backend Pro

This is a very powerful solution which can be made to meet any problem, you just have to find the way you need to use it.

[eluser]lightnb[/eluser]
So are AXOs independent from ACOs then? The actions (AXOs) don't belong to specific objects or groups of objects (ACOs)?

It seems like the "AddForumPost" action should only be associated with the "Forum" object and its children, since that action makes no sense in the context of an article system...

[eluser]adamp1[/eluser]
Yes AXO's are independent of ACO's, they belong to the actual access rules.

The reason for this was a design decision by Neophyte. Reason being if you look at the phpgacl implementation you have a lot of repeated information. I agree with the design decision, makes it simpler and you don't really need multiple Add actions.

Why not just have an 'Add' action, then its abstract enough to work on both 'Forum' and 'Article'. Remember if you wanted actions to be linked to control objects you could. They wouldn't be linked in the actual ACL system but when creating new permissions and such it would only show the actions connected to that resource.

[eluser]lightnb[/eluser]
I see what you mean by "difficult to manage".

I *think* I've got the hang of reading data, but I guess I'm going to have to build a control panel interface for adding/modifying groups and permissions, like the screen shots on your website.

Trying to do it manually in PHPMyAdmin seems error prone...

My page render time went from .05 to .27 when I check the permissions for a single test user- and that's just the Forum permissions. Obviously faster is better, but what is a good time to shoot for?

I'm thinking that this script will run once at log-in, and then save all the values as a session-var array? Unless that's a bad idea?

[eluser]adamp1[/eluser]
It is a bit heavy, I personally don't know about the execution time, haven't looked into it that much. What I think would be better maybe is since you have a lot of permissions to check for is have a cache system.

So instead of doing huge amounts of work on first load, do the work when needed, but store the results away so you instead spread that execution time over many page loads. The other advantage is they may not require all the permission checks, so it means you only do the check if you need to check for it. Get me?

There is probably ways to optimise the library but will save that until my management area is fully working.

[eluser]Neophyte[/eluser]
now that i finally have a few days off for the easter break i should be able to add some features ive been looking to add for a while now, these currently include :

helper function 'kh_acl_check' this will work identically to khacl->check() but will be stand-alone so on the bulk of pages where you simply need to check a users access you just use this helper (i would envisage this helper being the part you autoload and the library being manually loaded on an as needed basis when you need to manipulate the rest of the ACL)

caching support, i'll also have KhACL autodetect if KhCache is available if so it will where appropriate cache the results of a check.

I will also see about optimising the check code but due to the cascading nature of the permissions the more you nest ACO and ARO objects the more recursive it will become (optimisation suggestions of the check method are always very welcome)

Last of all if anyone has any requests then now is probably the best time to make them known.

[eluser]adamp1[/eluser]
All sound very good, I know trying to get the library running fast is very important, as said no point loading all the management code if its not needed.

How would caching work, when a check gets performed it gets stored away? That would increase speed hugely.

Also hopefully my BackendPro application will be finished soon, so you can have a look at how Iv used this library in a full application.

Just don't go changing anything huge or you will give me a huge headache

[eluser]adamp1[/eluser]
I have a change I think which would be better. Basically it upgrades the database scheme. I have used InnoDB tables instead due to the ability to have foreign keys. I have also looked at your code which you used to perform the selects and added more INDEX's and UNQIUE INDEX's to speed up the fetching of data.

Code:

--
-- Table structure for table `khacl_axos`
--

CREATE TABLE IF NOT EXISTS `khacl_axos` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `name` varchar(254) NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- --------------------------------------------------------

--
-- Table structure for table `khacl_aros`
--

CREATE TABLE IF NOT EXISTS `khacl_aros` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `lft` int(10) unsigned NOT NULL default '0',
  `rgt` int(10) unsigned NOT NULL default '0',
  `name` varchar(254) NOT NULL,
  `link` int(10) unsigned default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`),
  KEY `lft` (`lft`),
  KEY `rgt` (`rgt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- --------------------------------------------------------

--
-- Table structure for table `khacl_access`
--

CREATE TABLE IF NOT EXISTS `khacl_access` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `aro_id` int(10) unsigned NOT NULL default '0',
  `aco_id` int(10) unsigned NOT NULL default '0',
  `allow` char(1) default NULL,
  PRIMARY KEY  (`id`),
  KEY `aro_id` (`aro_id`),
  KEY `aco_id` (`aco_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- --------------------------------------------------------

--
-- Table structure for table `khacl_access_actions`
--

CREATE TABLE IF NOT EXISTS `khacl_access_actions` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `access_id` int(10) unsigned NOT NULL default '0',
  `axo_id` int(10) unsigned NOT NULL default '0',
  `allow` char(1) default NULL,
  PRIMARY KEY  (`id`),
  KEY `access_id` (`access_id`),
  KEY `axo_id` (`axo_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- --------------------------------------------------------

--
-- Table structure for table `khacl_acos`
--

CREATE TABLE IF NOT EXISTS `khacl_acos` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `lft` int(10) unsigned NOT NULL default '0',
  `rgt` int(10) unsigned NOT NULL default '0',
  `name` varchar(254) NOT NULL,
  `link` int(10) unsigned default NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`name`),
  KEY `lft` (`lft`),
  KEY `rgt` (`rgt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- Constraints for dumped tables
--

--
-- Constraints for table `khacl_access`
--
ALTER TABLE `khacl_access`
  ADD CONSTRAINT `khacl_access_ibfk_2` FOREIGN KEY (`aco_id`) REFERENCES `khacl_acos` (`id`) ON DELETE CASCADE,
  ADD CONSTRAINT `khacl_access_ibfk_1` FOREIGN KEY (`aro_id`) REFERENCES `khacl_aros` (`id`) ON DELETE CASCADE;

--
-- Constraints for table `khacl_access_actions`
--
ALTER TABLE `khacl_access_actions`
  ADD CONSTRAINT `khacl_access_actions_ibfk_2` FOREIGN KEY (`axo_id`) REFERENCES `khacl_axos` (`id`) ON DELETE CASCADE,
  ADD CONSTRAINT `khacl_access_actions_ibfk_1` FOREIGN KEY (`access_id`) REFERENCES `khacl_access` (`id`) ON DELETE CASCADE;

Another thing I have done is changed the varchar lengths from 255 to 254 since some server software doesn't support 255 chars, I suppose I just do it to try and make my database design as easy for someone to use elsewhere.

I don't know if using the InnoDB would be hugely slower, but since when you do a check() you pull all the records and loop through iteratively I don't think it will be too much slower.

EDIT: One more thing, using InnoDB tables will also mean that some of the DELETE queries can be removed, making the library simpler, and of course can use transactions.