Welcome Guest, Not a member yet? Register   Sign In
Khaos :: KhACL

But surely by doing that it will look for a access rule with 'username' and 'area'. Find none since none was specified for that user it was specified for its parent group. And then create a new entry, it won't modify the current one.

OK so lets go over some code using the example you gave.
// OK first lets create some users belonging to a group

// This is what we want to restrict access to

// These are the actions

// OK lets first allow all users to perform all actions on the group

// There we go, but hand on we don't want Bob be able to perform
// any action so we do

OK so there we go we have got the system we want, now when the deny command is called it will lookup a row in the access table with values matching 'Bob' and 'Website'. But it won't find any since we created the access rule using a higher level group. So now it will go and create a new access rule.

So how does this example demonstrate that you need to store the allow value twice?

ok so youre wondering why i set allow to 'Y' in both tables when you do the following :


You can obviously see that when i do the check it first checks to see if the (ARO -> ACO) link exists and is set to 'Y' thats why you need the 'Y' in the first table (remember the axos are optional so this could easilly be 'N' as well in which case the user would be denied access there and then). If an AXO was specified the check code goes on to check the ((ARO -> ACO) -> AXO) link (again this could easilly be 'N' if we denied the ARO a specific action) which is why the allow field is needed in the second table.

Yes I just realised that. Was just posting as you did. Coz if you only had 1 allow field it wouldn't allow the person access to the ACO at all if you then disallowed them access to an action.

Seems this ACL stuff is proving a lot more difficult to get my head around. Am trying to build a management area for all of this but trying to show the access permissions in an understandable way is very hard.

Im thinking some kind of tree coz I have a table atm but its impossible to see what permissions apply.

If you can just accept that its basically 2 trees with some additional actions and that permissions work in a cascading fashion down the trees its not too bad (but youre like me and need to understand it in its entirety including all the code in which case it can seem a little daunting at first) it does get easy though.

If i had the time i'd like to write a small app (maybe in the form of a matchbox module) so people could easilly visualise and manage it all and give them an idea as to how they could implement there own user permissions management system.

Always alot of work on and not much free time though Sad

I understand the basics of it, and understand the whole how it works out if you have access. But trying to come up with a clever easy way to be able to look at the rules and understand them. I can possibly do it (with some work) but I want my users of the control panel to get it straight off, I want it to say straight away who has access to what. Without them having to sit down like I am and working out exactly why that person should have access to a certain result.

A good example is if you have only one deny rule in the system
Even though it says deny the user access to the resource using the manage action, it also grants the user normal (non-action) access to the resource.

Think I also found one problem, not with your implementation but say I want to grant a user Full access to everything. Well I can grant a ARO access to the root ACO, but if they want to use any special actions you have to grant those individually dont you?

Think I have my interface idea sorted, nice and powerful but still very simple to use. I was only thinking of how the actions just float about. IE not assigned to anything. I suppose unless you scan through all the code there is no way to figure out which actions should be allowed on what ACO's is there? The only other option is to link AXO's to ACO's but that still requires a human to update the information.

I suppose this ACL stuff is very powerful so only a developer or system admin would be using it, and they should understand what the system can do.

I suppose I could write a script which every once in a while scanned the files for my check procedures and constructed a DB table so when you select what ACO to restrict access on it would show you the available actions. Seems a lot of hard work tbh.

Interface idea is here if anyone is interested.

I made some changes to the delete functions for ARO & ACO. Reason being was your delete query wasn't working if the ARO/ACO wasn't in a access rule.

Now this query will delete the ARO/ACO even if it wasn't in an access rule.

The difference is I used LEFT JOIN's instead of JOIN's.

ARO Delete Query
$rs = $this->_CI->db->query('DELETE '.$this->_Tables['aros'].'
                                       FROM '.$this->_Tables['aros'].'
                                       LEFT JOIN '.$this->_Tables['access'].' ON '.$this->_Tables['aros'].'.id = '.$this->_Tables['access'].'.aro_id
                                       LEFT JOIN '.$this->_Tables['access_actions'].' ON '.$this->_Tables['access'].'.id = '.$this->_Tables['access_actions'].'.access_id
                                       WHERE '.$this->_Tables['acos'].'.lft BETWEEN '.$left.' AND '.$right)

ACO Delete Query
$rs = $this->_CI->db->query('DELETE '.$this->_Tables['acos'].'
                                       FROM '.$this->_Tables['acos'].'
                                       LEFT JOIN '.$this->_Tables['access'].' ON '.$this->_Tables['acos'].'.id = '.$this->_Tables['access'].'.aco_id
                                       LEFT JOIN '.$this->_Tables['access_actions'].' ON '.$this->_Tables['access'].'.id = '.$this->_Tables['access_actions'].'.access_id
                                       WHERE '.$this->_Tables['acos'].'.lft BETWEEN '.$left.' AND '.$right)

nice find, though assuming you are using mysql you will need to add the access and access_actions table to the DELETE eg :

$rs = $this->_CI->db->query('DELETE '.$this->_Tables['acos'].',
                                       FROM '.$this->_Tables['acos'].'
                                         LEFT JOIN '.$this->_Tables['access'].' ON '.$this->_Tables['acos'].'.id = '.$this->_Tables['access'].'.aco_id
                                         LEFT JOIN '.$this->_Tables['access_actions'].' ON '.$this->_Tables['access'].'.id = '.$this->_Tables['access_actions'].'.access_id                                      
                                       WHERE '.$this->_Tables['acos'].'.lft BETWEEN '.$left.' AND '.$right);

otherwise the access and access_actions table records wont be deleted (atleast in 4.0 and 4.1)

ChangeLog - KhACL - 0.1-alpha3

Thanks to adamp1 for picking up on this one

Fixed - Bug in khacl->aro->delete() aro not being deleted if no access/access_actions setup against the aro
Fixed - Bug in khacl->aco->delete() aco not being deleted if no access/access_actions setup against the aco

Theme © iAndrew 2016 - Forum software by © MyBB