Joomla! Discussion Forums

I'm sorry for the abasence Hackwar, I've been working in parallel on another code project with several thousand content items and I've been fearful of trying out your code while I was concurrently manipulating alot of various db tables directly (and not correctly). But I worked out those pesky IDs and reached stability today, so I can do some fairly deep testing if its helpful.

so I'll try the last RC or the next, if you're needing more help I'll try whatever you like now...

As I said, I hope to be done in the next 48 hours... I'm at the moment in the process of getting the output of the list-all-acls-function correct and then to edit sections and objects. This will be fairly simple. I will then work on the user-admin, cause he won't add users after my update. will make that an alternative user-admin component. The uninstall-function does not work either... If all this is done, I would be glad if someone could test this stage 1 ACL-feature. The content does not get indixed at the moment -> no rules applicable there.
My biggest concern at the moment is the performance, if someone could try this... the original admin interface has a testing environment that checks all rules for there execution time. I had times that were around 0.02 s, which is way to slow for my opinion. But this could well be because of my slow testing server... If the time does not get reduced significantly by the use of the Joomla-db-layer instead of ADOdb and the use of a faster server, I don't think that phpGACL will be used in Joomla. I strongly believe in it and think that it will get way faster response times, when I'm done. For those of you who wonder why 2 hundredss of a second is a lot of time: Joomla does a few dozen requests per page...

To give you a plan of my work for the next days/weeks:
Roadmap
versioncomment
0.1first release with ability to set rights for user. admin-interface adjusted to Joomla, Joomla user-admin fixed to work with ACL.
Release of documentation for developers and a manual for users.
0.2ability to control access to content and a test routine to benchmark ACL-rules. smoothing the user-interface, small bug fixes.
0.3usability release. Making the admin-interface newbie-proof.


The roadmap can be changed without further notice. I expect 0.2 till christmas and 0.3 somewhere in january. I'll try to stay in contact with the devs to see how my work can be implemented later into Joomla-core (depending on the performance.) I'll keep you posted.

Hackwar

P.S.: 0.1 will be available for Joomla 1.0.3. As soon as Joomla 1.1 is out, I will make a "0.1 for 1.1" release.

Very Cool ! 

Keep the good work

I'm sure you'll get the execution time down, once the right layers and caches are in place.

Now I'm done with a good alpha, so:

Release of ACL-enhancenment 0.1 Alpha
You can download the package here: http://www.mutasound.de/gacl/acl_0_1.zip
Included is an installation manual. READ IT CAREFULLY!
This is for Joomla 1.0.3, a version for 1.1 will be out, as soon as Joomla 1.1 is tagged and out for all. (Just want to have a solid code-base before doing something that doesn't work when 1.1 is released...)
ATTENTION: This is an alpha-release, I do not guarantee error freeness or that it works in any way. Use this on a testserver only. Whoever tries this on a productive system is stupid and does this on his own risk!

At the moment it looks really ugly, will make it nicer for next release.
I would be glad for any feedback.

Hackwar

Hi Hackwar,

Just emailed you a bugs-, php-analysis- and feedbacks-lists...and a very few small fixes

0.1 Alpha 1 is nice for trying to understand the power of ACL, but not ready for production of course...

We also need to brainstorm for a simpler yet powerful admin interface. ARO is almost ok, but ACL is way to complex for Joomla's simplicity, being not usable without a manual at hand.

Keep the good work, you're on the right track...

Not much luck so far. Upon attempting to install, I get a message saying import failed, wrong character set. I think the import is swedish and the database is utf8. Then upon adding other files the menus disappear. Would you like me to try with a different installation somehow?

mmmh, I didn't set anything for the db-type (swedish/utf8), I don't know how to solve this problem... If you don't install the component, the other files have nothing to work with. You could try and insert the SQL-querys by hand into your db and edit where needed... I will see what I can do, writing back soon.

Hi folks,
in the last days I made a few adjustments to the component and the API, so here is the new, visually enhanced ACL-component:

Release of ACL-enhancenment 0.1 Beta
There are still some bugs, for one you can't edit sections and objects at the moment and the editing of ACLs doesn't work correctly either, but all in all I made some good progress. It has a nice to look at menu, everything is in Joomla-admin-styles. a lot of bugs have been removed, its a bit more fool prove, overall, it looks better.
Whoever wants to try it now, you can get it here:
http://www.mutasound.de/gacl/acl_0_1_beta.zip

As last time, this is for Joomla 1.0.3 and a manual can be found inside the .zip-file.

I'm "releasing" this now, because I don't know when I will have time to do some more work on it. I would welcome any help in completing at least this initial port of the generic interface to Joomla. I'm still searching for somebody who can make a stress test and see how it all performs. I'm not experienced enough to do this. At last: it would be nice to here something from one of the devs in how far this represents their idea of this feature and if the API looks mature enough to use. I know the admin-interface is to complicated to comply with the "power in simplicity" rule, but I will work on that when 0.1 final comes out. At the moment I think it would be good to have a switch to change the backend to advanced mode, where you can set stuff like ACL. (Otherwise I would just hide it.)

As allways, I'm open for suggestions and comments of any kind.

Hackwar,

This is terrific work!  Thank you for all your efforts on this port, do know that the community is very grateful for your effots.

To the core dev team:  please make sure, that if appropriate, someone on the team is able to pick up where Hackwar has placed this port.  This is an extremely important part of what users are looking for in Joomla, and I hope that it will be addressed as such by the team.

Best,
Ryan

Hi,

The work in extending the ACL is excellent. I have been playing with some custom changes to an earlier version to extent the group access.  I am trying to understand how it is envisaged that the ACL would be used to control access to menus, content, etc. My understanding so far is..

For the Front end :

Every User is part of a ARO group
The actions (ACO) for com_content would be add, edit, publish
The ACL would then link the ARO groups to the ACO

A user would then be able to view any menu, content, etc assigned to the level of his ARO group (or parent groups) and if by ACL permission also add, edit or publish.

I don't understand how AXO could be assigned at the content level. I thought AXO would be used to assign a set of rights that don't fit easily/simply into the group hierarchy, for example, give the marketing group rights to control publishing on the public site, give Human resources the rights to control publishing on the Intranet.


For the Back End :

All backend ARO groups would have view, add, edit, publish on all frontend content.
The backend actions (ACO) would be add users/categories/sections, edit menus, install themes\components\etc, component configuration...
3PD would create new ACOs for their addin as part of installation.

The assignment of menus/content/etc to and ARO Group is straight forward. Pulling the drop down from "#__core_acl_aro_groups" instead of "#__groups".

I have two questions.

1. Typically menu/content/etc are selected with an sql statement including a where statement like

"access <= $my->gid"

For it to be selected using the ARO groups this would need to be

"access in [$my->gid or any parent group]"

How can the parent ARO group list be generated?

2. When a user adds a content item, it can be assigned to their ARO group or any above.
How can the default be set to the User level?

For Example, assume we have two user groups Red & Blue
We then have Red Authors, Red Editors and Red Publishers, similar for Blue
If content is added by a Red Author its access level should not be "Red Authors" but "Red User"

Regards

I think the boolean paradigm

if (my->access >= this->access){}

should be replaced by some membership function:

if (mosismemberof(my->access,this->access){}

Because permissions do not always fall in hierarchical relationships. As to the UI, those folks who need complex access levels are not going to be intimidated by complexity. In fact they will welcome it. I think it would be a mistake to 'dumb it down'.

I think developers may prefer setting up groups with  XML files, and in many cases a mambot to implement permissions would make things alot easier. Just my two cents, you're welcome to disagree. 

Hi kiple,
your not exactly right with your assumption. First of all, there is no difference for the ACLs if its backend or frontend and there is no need to put every ARO (e.g. user) into a group. The only thing you have to do, is putting every object (no matter if ARO, ACO, AXO or ACL) into a section, but this is only for the sake of the users overview (Think about a site with 10.000 users. All in one big list would be terrible inconvenient. Its inconvenient now allready, because all object, sections and groups are send over to the Admin each time he loads the ACL admin-page. Way to much traffic, have to put ajax in here...). You can then assign actions (ACOs) to users or user-groups (ARO or ARO-groups). You can assign multiple groups to one user (for example a guy who is a forum moderator, publisher and maintainer for one special fork of your site). When you need more granularity than actions the user is allowed to perform, you can add AXOs, which would be the content. (for example allow user1 to view the article about really big mice and user2 only the article about the small and pretty ones) Again you can use Groups as with the users.


You would not create an ARO parent list. For this you have the function acl_check. Your typical call would look like this:

This function automatically checks if the user which is currently logged in is allowed to take the requested action, no matter in which group he would be. The AXOs are not necessary, if you use them, you would have to most likely hand over the content-id and you would get a true/false back, or, if specified, a certain return value. To summarize: You don't need to do anything, except calling this function and hand over the user, the action he is requesting and optionally the item he wants to perform the action on. Then you will get a true/false in return, where false is the standard value if no  rule applies.


As I wrote above, the content would not be automatically assigned to a certain user-group. It can be assinged to a special AXO-Group and all users that have rights on this group, can view. (or edit, or delete, etc. depending on what is set in the rules)

@emeyer

to 1.: As written above, there is a function that checks if the user currently logged in is allowed to perform that action (on this content). This is absolutely non hierarchical. You can create your own user groups in a flat structure and give each of them different rights. If you form a tree, higher groups just inherit the rights of lower groups.

to 2.: I thought about a way to install ACL-rules, objects and groups by a xml-file. The idea was to enrich the normal installer with these commands to prevent the 3PD from having to mess with the whole thing themself.
I don't know if this was what you had in mind, if you think of a permanently xml-based user-rights-managment, I don't think that would work. The performance of my solution is not really tested at the moment and on my testserver it needs 6-8 ms to make a query, which is in my opinion to long. (I got these values from the generic ACL-interface, which is based on ADOdb and I hope that the rewritten API to work with the Joomla db-layer will work faster than ADOdb) XML on the other hand is as far as I know at the moment the biggest resource waster in Joomla and a reason a lot of people have trouble with their sites. I will push the idea of an xml-format to install/add ACL-objects, but I wont support an xml-based ACL.

Hi,

Thanks for your reply. I think I'm starting to get the hang of it. 

I think you do not envisage the access to content being automatically restricted by the user access level. The current environment allows the restriction of access to content by including a statement in the sql "where access <= $my->id". This means the query only pulls relevant content to display. In order to only display the correct content items in a multi level environment will require pulling all content items and then cycling thru the items using the acl_check you mentioned.

If the content items are not asssigned an access level then the administrator would be involved in creating AXOs every time new content is added (if it has to have restricted access).

What I'm trying to think about is a way to a simple level of administration control using ARO and AXO groups that then can be used in the SELECT of the content. The more complex ACL-AXO rule can then be created/used by advanced admins and 3PD for a finer level of control.

I envisaged a set of ACO like (view, add, edit, publish)

A hierarchy of ARO groups like

Public
  Restricted
    Restricted Authors
      Restricted Editors
        Restricted Publishers
      Blue Team
        Blue Team Authors
      Red Team
        Read Team Authors

A hierarchy of AXO groups like

Public
  Restricted
    Blue Team
    Red Team

Adding a general ACL-AXO of Public, Public, view would percolate down the hierarchy allowing Blue Team to view [public, restricted and Blue Team] content. More complex permissions are possible using advanced ACL-AXO. By putting the users in a ARO group and the content in a AXO group a simple user admin screen can be created. I think

I need to build a gacl test to check this out.

I understand your comments on frontend v backend but there is a naturally different set of actions (ACOs) to be perfromed in each environment.

Regards

Kiple

This is all fairly easy. The AXOs will get created for every content-item and they will be assigned to a group you can determine. For example a group where everyone has access to by default or a restricted group. To get the correct rule for the content, you would just have to see, which content is requested and send these IDs through the check. I would estimate on a normal page this would be probably a dozen requests. There is even a function to allow batch-processing. The build-in caching will speed things up a bit to and the Admin would only have to once set his environment, after that, the authors can move the objects around freely. It could even replace things like the published-value, just give it an extended return value and only the authorized user can see the item in the online-page or tha its even there.


1. You don't need a hierarchy. You can set the groups as you like it, it doesn't matter. Just when you want a group to inherit the rights of another group, you can put them in a higher branch than the others. Don't think in hierarchys, its something Joomla should get away from. You could well have a user that is allowed to get into the backend and edit the preferences of for example the forum there, who has otherwise no other status.
2. There is no difference between backend and frontend, at least from the access-managments point of view. Sure you need different rules, but this has nothing to do with the front or backend. It wouldn't matter if you put the admin-interface of your component on the front- or the backend, you just have to set rules.

You just have to believe me that its all way easier than you think it is. You, as an Administrator, wont have to create anything but special groups and those only if you really need them. You wont have to use the whole ACL-interface either, cause its coming with good presets. Every component that uses this function will idealy install the needed objects itself and rules will be set by default to reasonable values.
This is an API that has a lot of power, but if coded right from the core devs (and probably me), its going to be as easy to use as a book.

Did you take a look into the component and installed it? Its not completely perfect and at the moment the patches for the core components to use it, are not out yet, but it will give you a pretty good idea what I'm talking about.

hackwar

Hi,

First of all thanks for taking the time to explain your concept of how it could work.

I have installed the component and the phpGACL demo.

Obviously until core patches the extended permission as yet do not impact the frontend menus or content. I am starting to get a clearer picture of how that could happen. I'm not sure that a AXO would be required for every menu/content item. A single AXO for each public and restriced group would be sufficient. The new content could be assigned to AXO using the same access drop down box filled from the AXO table. The AXO id would be stored in the access field. On menu/content display the access field would allow the ACL to check permissions before display. There would have to be some changes to the way the core files pull the menus/content but not too many. I think I give it a try with the menu system.

I think hierarchies work well in inheriting permissions for users and user groups. I agree with your point about not needing them for the AXOs.

Regards

Kiple

You have to make an AXO for every content-item, otherwise you can not assign it to a group or even question the acl_check for access rights. You can not write the AXO-id into the content-table, because we want it to be usable in all modules and components in Joomla and not just the com_content.
To include it in every part, you just have to put an if-clause at the right point. if ($acl->acl_check(parameters)) { - and you're done. What has to be changed is the way the content-items are stored. You have to add the call to add an AXO to it. This all should be a matter of only a few lines of code.

I'm working on it and hope to get something ready as fast as possible.
Hackwar

Hi,

Thanks sorry I'm not explaining myself very well.

Assume there are three AXO in the AXO section Content (Red, Blue, Green)

When content is uploaded, the access drop down box is populated from the AXO table,
choices (Red Blue Green). The content is stored with the AXO id in the access field.

There is a ACL-AXO rules allowing 'view' for various user groups to the AXOs

On loading the content, you select everything from a category/section ignoring access, each row is checked using
acl_check(action, view, usergroup, content, content->access [the AXO id])

This means the you wouldn't need a AXO per content and thus no new ACL-AXO rules for new content.

This seems easier to me, I must be missing something.

Are you supposing that the content will have to co-exist with modules and component that have not been updated to use the enhanced ACL? I think there are more fundamental issues with co-existence, for example, the hard coding of the Super Administrator group to gid=25. In the aro groups it has a gid of 11. Any change this gid has further implications into core files. gid and access occurs about 60+ times in the core files.

Looking at the menu sub system, I think there are about three places it needs to change, two in the admin side to select the menu AXO and one in the mod_mainmenu code.

Regards

Kiple

When you create a new AXO-item and assign it toa group, you don't need a new rule.

The gid-part is the next thing, thats making me problems, I will see, what I can do.

Good catch! Nice advances! Watching this thread as nearly as I can, will need that very soon, so will hopefully have more time than just for reading the thread. 

Confirming that gid is not only used (hardcoded ) in the core, but actually also in most 3PD components.

This must remain compatible for the backwards compatibility.

Hi,

I trying to look at what it takes to get the menu system to use enhanced acl.

This option creates a AXO item in AXO section menu for each menuitem.
The AXOs are added to the AXO group menu->public

The Public Frontend has a acl allow for the AXO group menus->public.

The adding/editing of menu items updates the AXO.
The AXO name & value are set to the menuitem id.

The menu display uses and acl_check on the menuitems to filter
the menuitems prior to display in mod_mainmenu.

I found I needed to create a ARO for guests and assign it to the Public Frontend.

This does not appear to be possible. The [Assign ARO] doesn't appear to do anything. I can create it by adding a new user but then I need to change its ARO value to 0. BTW I could get the delete of AROs to work either.

Regards

Kiple

Hi,

Still lost in the acl.

I can't seem to add new acls.

I created a ACO menu in ACO section action
I created a new user guest. (used sql on the database to get the AXO value = 0)
I created a AXO section menus.
I created 25 new AXO for the menuitems
I created a new AXO group menus->public
I assigned the 25 menu AXO to the menus->public group

I added the acl linking
  action->menu with ARO group Public Frontend with AXO group menus->public

It said done but the #__core_acl_acl did not have a new entry.
The acl list did not contain the new acl.

Regards

Kiple

Hi,

I think I have a working menu system based upon the extended ACL based upon the previous posts.

I had to make changes to mod_mainmenu and admin.menus.php.
mod_mainmenu to use the acl and admin.menus.php to create a menu AXO.

I had to create some ACOs, an ARO for guest, AXOs for menus and some AXO groups.
Then link then together with ACLs. Here is what I learned:

1. It seems to be as fast as the original site, but for 10-15 menuitems I don't think I could see a difference.

2. On editing users, the ARO update in joomla.inc line 2133 does not work.

3. There is a return missing from line 135 of Hackwars updates gacl.class.php.

4. The Assign ARO to groups does not appear to work.

5. To get ACL entered you must use 'Save' at the top not 'Submit'. (Fixes previous post)

Other than that it was straight forward. :)

There are a few bits I don't like.
a) The access level set in the menuitem having no impact.
b) Having to know the menuitem id to move the right AXO around.

I was thinking of trying a different way.

The access levels of menu items are taken from AXO items in section menus.
The administrator to set the access of the menu item to an AXO id using the menumanager.

The menu display by mod_mainmenu would use an acl_check on the menuitems->access to filter
the menuitems prior to display. This method would not be backward compatable but has a simpler interface.

Then I would like to have a look at module access.

I can mail files if anyone has an interest.

Regards

kiple

to 3. Fixed that.

to 4. I hope you are aware that this is only a beta at best and its likely that there will be changes. I'm going to do my best to make a nice version of this. You just will have to be more patient.

Sorry.

I know its a beta. I was just recording what happened. Posts can come across as very impersonal. I did not mean or imply any dis-satisfaction with the efforts that have gone on.

Regards

I don't feel assaulted or anything, I just have the impression you start developing something based on a tool thats not ready for any development other than its own yet.

Basically, I have the need for the finer access control it offers. A previous hack of mambo to do this has proved too limited in flexibility.  The stuff that I am doing is simply to understand how a full ACL would be used, more a play than a development. Thats why I picked menus - far simpler than content.

You obviously have a fairly advanced conceptual framework of how it would be used and I am interested in that concept. Is it better to leave things for a while to allow you to flesh out the concept? My view on the component just now is very positive. You have done a great job porting it from the adodb. The acl_check works great. Improvements in the admin side will depend upon how the acl is to be used with content, menu, modules etc. But it works just now to get the basics into the system.

Regards

Kiple

Hi Kiple,
yes, I have a somewhat advanced concept on the usage of this component/hack. I'm working on all this, most of the time in my head. Thank you for your compliments. You can off course use the component at the moment, it's just that I'm still working on that &!"§§$ interface and it will need a lot more time till I can declare this function stable and with the necessary features. When I started it looked like a project for 2 days and I couldn't really understand why the devs hadn't taken this task allready, now I see, that its hundreds or even thousands of small problems and a lot of code to change all over Joomla, or at least several tricky workarounds to implement.
Work progresses fairly quickly ...when I get time to work on it.
Hackwar

Hi,

I have a current issue to resolve. I have about 40,000 resources (files/graphics) to manage access to. I need to do it in a coherent flexible manor that extends to the whole site. I need to continue to explore. I suspect that the operational concept that is forming in my head is different to yours.

If I come across anything interesting I'll report back here. Needless to say, if there is anything I can do to help you move forward you only have to ask.

Regards

Kiple

mmmh 40.000 items is a bit much to do by hand. You would have to write a little script that takes the informations necessary and adds AXOs for these items. You can also very easily assign these to groups you (automatically) created before. I don't have time to do such a script at the moment, but I removed a few more bugs from the component and API. I wrote you a link by PM where you can receive this modified version.
You could start developing on this basis, but as I still hope to get this into Joomla, probably allready completely in 1.2, and this will/would get a standard which will most likely have changed till then, I don't really recommend it. You could do a lot of work and later be stuck with this. I don't know if you can wait a longer period of time, till 1.2 is out, or at least till the devs have agreed to use my component and furthermore agreed to certain standards, but if you start now, it could all be for nothing when they disagree with my stuff "in the last minute" and choose another path.

The script is no problem. Over the last few days I understand how to auto create AXO and groups. My real concern is about having 40,000 AXOs. The opportunities for caching are very low. But there are spread over about 20 user groups. I was thinking more of creating 20 AXOs (for each user group) and then linking the resources to the AXO by some access number = AXO id. Opportunities to cache hits very high for only 20. But to do the same with standard content menus etc is not backward compatible.

I did a hack on mambo 4.5.2 to get 16 user groups. It took about a month. 1 week figuring out how. 1 week coding. 2 weeks testing. Site is live now but off course there is a few unpredicted permission inflexabilities and there is a requirement for more groups. If I'm going to do it again I might as well do it with a newer version. 

As you can see I'm already in the trap you describe so well. I don't think I can wait for 1.2. I have a window now for doing the work. Reinventing the wheel is not a problem if it lets you get a shiny one before everyone else  .

Regards

Kiple