The Joomla! Forum ™

I'm trying to track down (and hopefully document, if I can figure it all out) the behavior of the ACLs as related to users and content.  I'll post more as I learn it, your help is appreciated if I'm wasting my time on something that is already nicely written down somewhere.  Thanks.

[Note, some basic behavior seems to have been adopted wholesale from phpGACL, http://phpgacl.sourceforge.net/.  Their page explains some of the intent of ACO, ARO, AXO below.  It doesn't seem like all of these behaviors are relevant to Joomla, which might explain these empty tables.]

Database Tables (thanks to http://www.bedre.no/images/stories/graf ... schema.png for the Database Schema which helps as a starting place):

• jos_core_acl_aro_groups : this defines the groups you see in the backend for user assignment, such as "Registered", "Author", and "Editor".  This appears to be slightly hard-coded -- if you were to add or remove groups directly in the database, it looks like some of the behavior would be broken.  Eventually I'd like to modify any files depending on hard-coded IDs (the _getBelow() function in libraries/joomla/user/authorization.php reference specific lft and rgt values 3 and 22).  Additionally, the jos_users table seems to have both gid and usertype, which both pull data from this table.  It seems like one of the two could easily be eliminated to reduce redundancy in the system.
• jos_core_acl_aro_section : this database table contains exactly one entry, 'users'.  phpGACL indicates that this table is intended to define classes of requestors -- "browsers" or "users" or "servers", for example.  I'm not sure how to make profitable use of this in Joomla.
• jos_core_acl_aro : this table seems to define a many-to-many relationship between assign specific user ids and specific aro_sections.  So this would imply that while a user belongs to exactly one aro_group, he/she may belong to many aro_sections.  Perhaps this could be removed without any real consequences.
• jos_groups : defines the content group types Public, Registered, and Special, that you see in the back end.  I assume there is the obvious coupling between this and jos_core_acl_aro_groups, but it's not explicit anywhere.

The actual mapping of these access categories seems to happen at runtime and be coded into the core joomla framework and the components themselves by using the JAuthorization (JFactory::getACL() returns the runtime instance of this, it seems) class defined in /libraries/joomla/user/authorization.php.  This defines the addACL() function that defines the following parameters:

• aco_section_value : this defines the component of interest - login, com_user, com_banners, etc.
• aco_value : seems to be a component-specific value - for example, login might define 'site', but com_user wouldn't know that value
• aro_section_value : this is always 'users' in this version and would presumably be tied to jos_core_acl_aro_section table above.  Perhaps this informs the expected utility of that table?
• aro_value : this comes from jos_core_acl_aro_groups and indicates the minimum required group for access
• axo_section_value, axo_value : unused, mostly - com_content seems to define 'all' in the axo_section_value parameter.  Input?
• return_value : a few values in com_user use this, seems to be from jos_core_acl_aro_groups, but I haven't dug around to find out why

Usually the appropriate access is tested by calling $user->authorize(aco_section, aco, axo_section, axo), which downcalls into JAuthorization::check_acl(), which has basically the same parameters of addAcl but without return value.  Again, aro_section is always 'users' and 'aro_section_value' is replaced with the usertype or userid, depending on the use of 'full' phpGACL or not.

So an untangling of the table together with a back end management system would probably make for a much more powerful ACL system.  I think this is what JACL+ has done (or some similar enhancement), but it doesn't seem necessary to do it so that it breaks the existing modules, although I could be wrong on this point (I just started looking!).  This is my goal, as I need to create a system that provides for several different classes of registered users to have access to different areas of the site, and within those classes I would like some users to have editorial access, etc. 

If anyone has input on my understanding the current system (either corrections or reference to more information) please let me know.  If anyone has a more painless way to introduce the behavior I'm looking for, please let me know.

I also read that an improvement of ACL is targeted at 1.6 -- is this something where scoping has already been done?  If so, how can I become involved in that conversation rather than duplicating effort?

Thanks,
-Paul

Ok, having done a little more research on phpGACL (read http://phpgacl.sourceforge.net/manual.pdf), it looks like it is a reasonable way to offer slightly more configurable and slightly more fine-grained access control without changing what is there and seems to work.  I saw some of the comments against the full phpGACL, and I don't know what to think of them yet -- however, since my bias is toward doing as little work as possible, I'm not going to swim upstream and propose an entirely different ACL model -- even assuming I was well versed enough to do so.

Here is what I'm thinking:

Observation 1: ARO

ARO - "Access Request Objects" -- things that request access.  In phpGACL, these have a "section" and a "value", and may be nested.  The section is used in a degenerate way in Joomla, as it is always 'users'.  The "value" is a group, giving the familiar arrangement of:
Public Front-End
- Registered
  - Author
    - Editor
      - Publisher
... where each child inherits rights assigned to the parent.  The hard-coding I mention earlier is used to prevent people from choosing "Public Front-End" or "Public Back-End" as actual groups.  This is a hack and could be fixed in a number of ways - I propose one in Action 1.

* Action 1: Add section_id to jos_core_acl_aro_groups table, use acl_aro_section to define section names, remove acl_aro after removing any stray references to it.  This fixes the "public front-end" and "public back-end" hack, as they become proper section names associated with their respective levels.  This also allows us to add our own custom groups and sections --> NOTE <-- this will probably break some existing software unless a hack is put in to map or fake existing categories, or Action 6, below, is implemented as well.

Observation 2: ACO

ACOs, "Access Control Objects", seem to be a pretty good mapping that allow components/plugins/what-have-you to register their own actions and capabilities.  I don't see any reason to modify this except maybe it would be good to put them in the database someday and have a more consistent documentation requirement so we can find out which components support which access-restricted actions.

Observation 3: AXO

AXO, "Access eXtended Objects", are largely ignored in the implementation today (I need to do a little more searching to confirm this).  However, as described in phpGACL, they are perfect for offering a more detailed level of control over content (and possibly other areas if that makes sense).  Today, the functionality is being offered by the "jos_groups" table, which is a very weak version of the AXO capability.  I think this can be fixed without breaking the system as it stands:

* Action 2: Change meaning of jos_groups to be AXO values; maybe make a new table with an alias to the old one, maybe just be clear about the use and allow developers to do their own translation in the short term.

* Action 3: Add a section_id and axo_section table to allow components to register their own axo values (previously jos_groups), just like AROs after Action 1.  This allows us to restrict this behavior to the com_content component initially, and not confuse anyone else. 

* Action 4: Create the ability for admins to define their own content access groups by defining new AXO values for the com_content component and assign them to content sections (or articles, I suppose, but sections is enough for my needs).

Observation 4: This is probably enough for a slightly more customizable capability: now I can define some of my own custom user groups (AROs), and content access groups (AXOs), while the components define the relevant actions (ACOs), as they currently do.  It results in slightly more complicated

I'll probably stop here, but the next steps to getting a completely flexible phpGACL implementation should also be:

* Action 5: Define an "Access Policy" back-end component that allows definition of linkages among AROs, ACOs, and AXOs, as described in the ending pages of the phpGACL manual.  This is directly supported in the phpGACL check_acl function, so once the control panel is built to edit them, the logic of checking them should already be done.

* Action 6: allow users to belong to more than one aro_group -- create a new table to allow many-to-many between the users table and the aro_groups table.  At the very least this is valuable for backward compatibility; more complicated ACLs are also possible (caveat in the phpGACL document that this now permits ambiguous access rights; should probably be looked into more carefully).

That's all for now.  I'll keep you updated on progress.

Hi Pacovell,

I have been working with Joomla for quite a while now (6-7 months) to set up a better framework for my company's internal network... I am not even close to be an expert in this, so take what you think is true from what I will say and debate the rest...

phpGACL is (IMO) a good implementation to allow multiple groups and granular access to objects. The Joomla team (not wanting to reimplement the wheel) wanted to use its capabilities in the long run in Joomla. But for J 1.5 their first priority was to implement a new framework (and probably some other things), so they kinda took a slight attempt in having phpGACL in place. Which means they implemented some of the tables, hard coded the 'users' section and some other things. (They hacked something together for temporary usage. - Not complaining, just stating!!)

I have seen part of Andrew Eddie's rokACL (only the code, I have not attempted to run it yet). They say this is going to be the basis for groups in a J 1.5 component (which I do not know how they will develop without hacking core files) and group access in J 1.6. In this component Andrew added the rest of the tables that phpGACL uses, and as it looks like, he also implemented the administration back-end component (the actual adding of groups and different permissions). If you wanted to look at this code (possibly put it in place and see how it runs), you can check it out from here:

http://joomlacode.org/gf/project/rocket ... pathrev=57

As I said, I only peeked at this, so I am possibly wrong about what I said above. I am also not an 'official' Joomla developer, therefore I am just speaking from the knowledge I gathered in forums, emails and my own experiences with Joomla.

The problem here is not only how the groups and access are defined and implemented, but that J 1.5 core files and components check against the old implementation and do not utilize any of phpGACL capabilities. Therefore if someone wants to implement multiple groups at this point, it seems to me, that hacking core files and/or reimplementing core components is necessary.

I think the ultimate goal is to implement full phpGACL and have the core use it. You seem to talk about phpGACL in a way that, as if implemented, it will be usable right away and I just wanted to say that it might not be the case.

Anyways... again, I am not an expert, so anything I say is debatable. Please also let me know if I am misinformed about anything I said above.

(and sorry for the bad English too)

cmaker

cmaker, thanks for the feedback.  I will take a look at what you recommend - perhaps it will save me some work.

By way of update, I've learned more and implemented more:

1.  Action 1 isn't really necessary to get a quick fix in line.  We'll just leave those alone.
2.  Action 2 is just a conceptual (mental) shift -- okay, jos_users is jos_aro.
3.  Action 3 is also unnecessary -- if we wanted to use the "full" phpGACL, it would be necessary, but AXO values don't change much, so this is probably reasonable.  Content is one of the only components that uses them, so we leave it alone for now.  Ironically, it also has the most hard-coded resistance to using ACLs... see below.
4.  Action 4 ... surprise - also unnecessary - same reason as 3.  COULD be dynamic, but we take a database hit and it's more work.

So what have I done?

Well, it turns out Joomla already puts jos_core_acl_groups_aro_map in the database, and stuffs a couple of dummy values in it.  jos_core_acl_groups_aro_map is the link between users and groups, allowing users (aros) to belong to multiple groups (aro_groups).  This is great, because now I can add new groups to jos_core_acl_aro_groups and add users to them, while leaving the hard-coded values there for backward compatibility.

Hacks:
1.  Have to hack authorization.php and user.php in libraries/joomla/user/ so that user.php loads an array of all groups the user belongs to and authorization.php checks all values in the array to see if one of them matches.  The nice thing is that it's totally backward compatible -- if the user turns off or doesn't use extra groups, no side effects happen.  An easier change would be to set full phpGACL to on, but that would require putting AXOs in the database and adding extra tables &c, didn't feel much like doing that.

2.  Some code (com_content chief among them, and many administrative components) actually explicitly checks $user->get('gid') < 19 or $user->get('gid') > 24, for example.  I can see the tendency toward care with security, so these would need to be patched as well before they could reliably work with this code.  I suspect that any parallel component such as rokACL would also need to patch or completely replace these components (or have a hideous hack of returning the "highest" gid value -- but that seems very risky and unpredictable).

So actually this works very nicely - I just need to add a back end module to add the items you were talking about.  Good for my learning but sad if it's already been done ;P.

This was a lot easier than I thought it might be, but the context necessary to modify the components took me a long time to acquire.  I should have started out by reading phpGACL's documents, then authorization.php, then user.php.  Note to other adventurers.

Cheers,
-Paul

We'll be discussing this in detail shortly for 1.6 and asking for public comment on topics - so keep an eye out for when that when it starts.  For me the challenges are not so much technical, but how that are implemented in the UI and how fine to we go with granularity yet still keep the simplicity of the current system.  Once the "how do people actually want to do ACL", then we work backwards to work out how to implement it.

The main think is to work out what compromises between granularity and simplicity the community in general will tolerate.  For example, doing a full on implementation where you can lock down a single user to edit a single document is a pretty big ask UI-wise.  I'm more leaning to the following:

1. Put "people" in multiple groups, and you can change what those groups can and can't do.

For example, a permission may be "Install an Extension".  You should be able allow or disallow someone in the Manager user group to be able to use this permission.  That's pretty simple stuff.

2. Put "content" in new groups (other than Public, Registered, and Special) and map user groups to content groups.

Here's the major simplification I'm working on.  You might have a permission for "View" and one for "Edit".

You should be able to create a new user group called "Club", and you should be able to create a new content group called "Premium".  You should be able to then be able to create a rule that says "Only people in the Club user group can view content in the Premium Group".

Finally you should be able to create a user group called "Moderators" and you can create a rule that they can Edit content from a selection of content groups.

I think you should be able to produce a lot of the results people are asking for with that sort of approach.  There's nothing stopping you from going finer, but it would require more work in the component and I think for com_content this approach would be enough.  The next trick is to keep the management of the ACL's easy as well - preferably as tick-and-flick as possible.

_________________
Andrew Eddie - Tweet @AndrewEddie
<><
http://learn.theartofjoomla.com - Joomla 2.5 training videos!
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

I prefer a more detailed ACL with many options as to how to control users/groups. I know it would require more coding, but I think it would benefit Joomla more.

I think that for "normal" users the best solution would be an easy to use ACL system like the one you proposed, but for bigger companies and people that want to use Joomla as a News Agency (like bbc.com ) they would like to have much more control on what users get access to or not.

My suggestion is therefore that the ACL is implemented in a way that makes it possible for developers to extend the ACP system so that it fits their own needs. That way you could have an easy-to-learn ACL in Joomla by default, but with the ability for devs to extend it to their own needs too.

Anyway, I suggest that before the ACL system is being developed you make a topic where you ask the community to propose what features (read: which permissions they want to be able to control through the ACL) they want to have in the ACL system. That would give some clues as to what to implement into it, and what to leave for others (3rd party devs). Using my approach you would probably satisfy 90% of the community, and the last 10% would probably be able to extend it to their own needs if they need even more control on the system.

may I add a link from another OS project regarding acl interface?
http://codex.gallery2.org/Gallery2:Usab ... ermissions
pictures are clarifying in some way, see if you can take advantage of them...

Thats why I'm leaning towards an exchangeable system, for example phpGACL, LDAP and MySQL and so on. If you need more granular settings and am using phpGACL, you could use the phpGACL user interface to set the rules. The same with LDAP for example. And that would work for small, medium and BIG business.

_________________
god doesn't play dice with the universe. not after that drunken night with the devil where he lost classical mechanics in a game of craps.

Since the creation of the Internet, the Earth's rotation has been fueled, primarily, by the collective spinning of English teachers in their graves.

I'm thinking along similar lines, that a plugin system "somehow" will be able to control what system you are using.

_________________
Andrew Eddie - Tweet @AndrewEddie
<><
http://learn.theartofjoomla.com - Joomla 2.5 training videos!
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

Got that working allready.

_________________
god doesn't play dice with the universe. not after that drunken night with the devil where he lost classical mechanics in a game of craps.

Since the creation of the Internet, the Earth's rotation has been fueled, primarily, by the collective spinning of English teachers in their graves.

another discussion thread of same topic here :
http://forum.joomla.org/index.php/topic ... 94895.html

NOTE: backup your  jos_core_acl_aro_groups table before attempting this code
tried the following sql code to add a new group  &  i think this is solved now ?

SET @parent_name = 'Registered';
SET @new_name = 'Support';

-- Select the parent node to insert after
SELECT @ins_id := id, @ins_lft := lft, @ins_rgt := rgt
FROM jos_core_acl_aro_groups
WHERE name = @parent_name;

SELECT @new_id := MAX(id) + 1 FROM jos_core_acl_aro_groups;

-- Make room for the new node
UPDATE jos_core_acl_aro_groups SET rgt=rgt+2 WHERE rgt>=@ins_rgt;
UPDATE jos_core_acl_aro_groups SET lft=lft+2 WHERE lft>@ins_rgt;

-- Insert the new node
INSERT INTO jos_core_acl_aro_groups (id,parent_id,name,lft,rgt,value)
VALUES (@new_id,@ins_id,@new_name,@ins_rgt,@ins_rgt+1,"Support");



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

access level
public ,registered , special

in joomla user manager

group
;
list of groups
ROOT
| - USERS
| -- PublicFrontend
| - - - Registered
| - - - - Author
| - - - - - Editor
| - - - - - - Publisher
| - - - - Support
| - - Public Backend
| - - - Manager
| - - - - Administrator
| - - - - - Super Administrator


Also, a suggestion if joomla can utilize its inbuilt explorer style tree for displaying group hierarchy will be a great addition
http://destroydrop.com/javascripts/tree/

I am not sure of the coding as I'm old and haven't kept up with such things.

However when you look at the tree structure in ukirfan's post, that appears to me to BE phpGACL structure. My hope is that moving forward with this we don't just think in terms of content creation, but also... and perhaps more importantly... of content DELIVERY.

The existing groups are the basis. The group functionality is there. Public, Registered, Author, Editor, Publisher.
In ukirfan's example tree he has added a group called Support under Registered. If Support inherits the access levels of Registered, then you have a read-only group that can see Public content, Registered content, and now Support content (and of course "Public" and "Registered" can NOT see "Support" content)

If you also created a Support group under Author, then a user in that group could submit content (inherited from Author group) and also see content assigned as Public, Registered, and Support.
If there is a Support group created under Editor, a user assigned there inherits Editor rights for Support group but not other groups... and so on.

Using this idea you could have Support under registered and Support2 under Support. Support2 can now see all content assigned as Public, Registered, Support and also Support2 (while Support can NOT see Support2 content)

In its simplest form there's your delivery system.

If you really need to take it all the way down to username level so that only a particular user could see some specific content, then you have a "Username" variable under Registered (They have to be registered to even HAVE a username and if you are targeting an individual then it doesn't MATTER what group they may or may not belong to)

At the user level... if they have Publisher rights only for the group called Support, then when creating content they see only the groups for whom they have Publisher rights. A group called "Support" if located under "Publisher" would give a user in that group rights to publish only for that group.

This is a basic explanation as I have limited knowledge of the coding necessary. How to handle an individual in multiple groups is beyond my current thinking and level of coffee intake. And I'm SURE there's more to this, but as a USER.... this is what I see.

And what I have been waiting for since way back in the Mambo days

".....How to handle an individual in multiple groups ..."


1. A user can be assigned any one group  (  joomla default)of the listed. (not a multiple group selection)
and you can create a child group( for any parent type of author , editor, publisher)  for a web user who has exceptional restriction requirements.

to clarify further:  http://help.joomla.org/content/view/476/153/

which says on Access Level type : Special
"...You could also decide to have only some items of the User Module configured with the 'Special' access. A 'Registered' user may have access to the 'Details' menu item but not to the 'Submit News', 'Submit Web Link?' or 'Check-in My Items' menu items...
"