Joomla! Discussion Forums

I removed a few of my links which were not valid any more. Please only use the most recent version of the ACL-package.

I thought about opening a new thread, because it gets a little bit messy in here. Everytime I point a user at this thread, he/she has to read to almost all of the 120+ posts... Suggestions?

Hi,

I'm trying to initialise some permissions for the user before the variable $my is initialised. It doesn't work because of this code in acl_check

} else if ($my->usertype == $aro_value) {
    $acl_result = $this->acl_query($aco_section_value, $aco_value, $aro_section_value,
                        $my->id,  $axo_section_value, $axo_value, $root_aro_group,$root_axo_group);

I know this is for backward compatability but is there any reason it shouldn't read

} else if ($my->usertype === $aro_value) {
    $acl_result = $this->acl_query($aco_section_value, $aco_value, $aro_section_value,
                        $my->id,  $axo_section_value, $axo_value, $root_aro_group,$root_axo_group);

which seems to work.

Regards

Kiple

I'm just replying regarding the PHP aspect for now:

The === is ok, but if you turn all warnings on, you will see that you get a warning on $my...

Better would be:


} else if (isset($my->usertype) && $my->usertype === $aro_value) {

Hi,

Sorry, I'm a bit late on following this thread but there is also another existing component called JACL: http://www.byostech.com/

Some of you may already know it but if you don't it is worth taking a look at it and test drive the component. It really has been very flexible in the custom group access i was able to create.  Download it here: http://developer.joomla.org/sf/projects/jaclplus

thank you,

sunburst

Hi sunburst,
I knew about this component, but with a lack of time and lots of work to do, I hadn't had time to look at it closely. Now I had and frankly I don't think its "the real deal". It sure is an improvement in comparison to the old default ACL-system, but it lacks somewhat the same problems the old one does. The way I see it, it just extends the old system by making it possible to create more groups and edit the rules that have formerly been staticly written in the gacl.class.php.
Please correct me if I'm wrong, but this component does not let you assign special rules for a single user, you would allways have to create a whole new group. Every user can only be assigned to one group and because the groups don't seem to inherit rules, you have to create every single rule again and again for every group. Furthermore it will not allow you to create content-groups to which you want to control access and you can there by not say "This user has special access to this article" without making a whole new group for him. I just think about a german site on which you can buy essays. If a user buys 2 essays and another buys one of the essays the first one bought and a second new one, you would have to create a new group for each of them. That is in my eyes not the kind of flexibility most of the users would like to see. I'm most likely wrong , but I will stay with my solution and try to improve that one.

Now: After I told so much bad about this component, I want to say the good things, too.
Most likely this component works a lot faster than the phpGACL. it makes just one db call to get the infos and thats it. This would make the access control part of Joomla almost as fast as its now. What I like most about this component is the easy way it is installed and I think I'm going to take a closer look into their install script. That is definitely a fine work of art.

Which of the two concepts is better has to be decided either by the community as long as the devs don't work on the new core-ACL or by the devs when its time to choose between the two. In matters of performance the JACLplus is at the moment top of the line, but I think my solution will be as fast when caching is activated. before this happens I have to look more closely on the caching part, but as allways, its just a matter of time.

So long
Hackwar

Many thanks for that insight. I do admire that the JACLplus has taken the default ACL a step further even though you might have a point about assigning special access for a single user which it can't do since each new group created must inherit something from the default groups (parent and child process) but this limitation lies in the default ACL (as you mention, quote below).



So your suggestion is to rewrite the whole gacl.class.php in order to break out of this limitation that exist? Wouldn't that be a every complex issue? 



I guess when you are able to assign special access only to a single user without the need to inherit from the parent or child, then this problem will be resolved. Is that right? Would there be any secuirty concerns?

Whichever one that the dev team might choose if they don't come up with one themselves, i guess it would be the one with the ability to allow to assign special access only to a single user/group since this will make any access level possible whether it will be for content, components or etc.

Good luck to you and the JACLplus developer whichever one will be better or not (i guess it's not the point). I think both components will serve the community well since we have such varied levels of users, some may chose one component over the other as it fits there need whether they require something more advanced or not. It all comes down to the complexity of a site users' are creating.

I'm just thankful that we have a choice in this matter :-) because of great people like yourself and others that go that extra mile.

Cheers,

sunburst

Hi,

The JACL component looks very good at what it does. The difficulty is that everyone is looking for something different. Some people are looking at very easy to implement extended groups, others want best performance, others want very fine grain permissions. The issue facing the dev team, who are the ones who will in the end resolve it, is to choose a framework that can support all of the requirements.

Having spent the last week playing with the phpGACL via Hackwars excellent port, I think an ACL with phpGACL at the back end can do that. The issues facing the use of the phpGACL are simple. The language (ACOs, AROs, AXOs very intimidating)  and the interface is very daunting for an inexperienced used, even a site developer  :). The performance would go down for lots of content with very fine grain access, lots of items = many cache misses = database access = time. I would propose that the phpGACL be used in a way that allows all the different administrator levels to work with and can pull in fine grain permissions when required. The operational concept that I have been playing with is as follows -

At the simplest level the admin can create new user groups in the hierarchy and assign action permissions of add, edit and publish to the new groups. The menus, content, sections, mambots, etc can then be given an access level of any user group. Its just extended user groups. This is achieved by automatically creating AXO for each user group and rules for create for view, add, edit, publish linked to the user group. The access field is used in content to refer to the AXO controlling permissions for the user (limits to 255 user groups). In this, the number of AXOs is small, cache hits are high and performance is good. I have alpha code done for this and there is no noticeable difference in speed to a virgin site. The changes are not extensive in code just scope. Basically the same changes in lots of files and some work arounds, particularly gid == 25!  :(

The next level is to be able to create custom rules on how the actions, user groups and resources groups interact. This would allow some very custom group hierarchies and permissions. It is the admin interface for this that would determine how many admins actually move to this step. I'm playing with some concepts on this now. Basically it can be very similar to menumanager & menus.

Then there is fine grain permissions. A rule can be created for an AXO group which links it to individual item privileges. The core detects this and instead of asking for ACL permissions on a user group it asks on an individual item key. The code changes are minimal form the simplest case. The user interface for rule create should make this straight forward.

I think this type of solution gives most admins what they want while still maintaining performance.

Regards

Kiple

If you look at the history of the file and the source it came from, you would see, that its a stripped version of the phpGACL-API and if you look a bit further you'll see, that I allready rewrote this API to work with Joomla. My solution can up till now upgrade every running site to work with this new system, although a lot of functions are not used yet. phpGACL is the system that was chosen initially by the Devs, but they stripped it down, because of lack of time. Masterchief expressed his excuse for releasing this stripped version, causing a lot of difficulties. I just caught up on his work.

@kiple
I think its hard to implement so many stages of complexities into Joomla ACL. I just think about the problems it will cause in the forum when people ask about it and you have to first ask everytime in which mode they are. I think the most practical way will be to supply it with good standard-values and initially hide this feature from the newbie. When the user is more experienced, he can choose to explore this feature and create rules for himself every way he wants.
About the AXO performance: I think it would be good to have the ability to choose if you want to group your article under one AXO or if you want to create a single AXO for each article. I don't know how intelligent the content-authors of big sites are and if you can teach them how to work with this feature, but I would allow the author to choose if this should be a new AXO or just added to another AXO. You could by that reduce cache misses and keep the number of AXOs low.

@Devs
Although I think I'm starting to annoy you again, I'm still waiting for a response. I want to do a bit work for you in creating this code and hope this gets included into the core, but when you don't tell me what your requirements are, I can't work on. Again I have the problem, that I don't want to change to much code outside of my component, which would have to again be changed in the SVN. I would greatly appreciate it, if you would tell me which way this whole thing is going. I want to devote time to this project, but wasting it by sitting here and asking my fortune-teller what the all mighty Joomla devs want, is not very efficient.

Hi,

We are talking about the same thing. There would be no optional configurations. By default the content is assigned to a one of a set of fixed AXOs. These are set up automatically, with rules, based upon the user groups. For many site admins this will be sufficient and there will be no need to do anything. For other site admins more complex rules will be needed and they can use the ACL admin interface to do this. If required the site admin can apply a rule making one of the AXOs contain individual content. When content is added to this group an individual AXO would be created and again the ACL admin interface can apply rules or group the individual AXOs.

Regards

Kiple

Don't want to minimize the incredible insight that HACKWAR and others have initiated here, so please forgive our simpleness..

Hack - we are having a hard time understanding your current position compared to kiple.

We have made a few hacks ourselves that resembled the JACLPlus but with more of what Kiple said. We are and were not doing it for anything at this level so we commend all the work completed to date.

We would like to see that someone that has this much insight and time to dedicate should get a little more feedback from the CORE TEAM in this matter.

That being said..

Hackwar, we would really appreciate it if you could share a small and simple description of your current understanding and path
in respects to your hacks. I believe there may be many of users who if this thread was simplified for them to discuss would help you and others see a larger picture so that all this work can be integrated with the greatest functionality, least amount of code, and unlimited growth.

we again thank you for all your hard work!!

I don't understand what you want me to do... Should I explain the ACL stuff again or what was your question? I'm a little bit confused...

Hack,
I read a thread in here but cant seem to find it again that specifically talks to features and functionality with ACL. When I said you may want to share a simple description or graph, thats what I meant. Many people here are not as fresh in the programming, but they may be able to help in the understanding of the needs and wants/wishes of the community. Your understanding so far has many questions that are opened. Just because your or even JACLPlus feel you are handling it in a proper way, most of us users want to know and enusre we all are included in the setup/understandings.

That being said heres what I would ask of the team and others. 

PER THE ROADMAP ACL stage 1 is in Q1 06 and 2 isnt defined. With the amount of people wanting this functionality and with the 2 people we know have developed some code towards this endeavor I would ask the following.

1. JOOMLA CORE -- Please create a subforum/thread or something strictly for this endeavor so people like HACK, JACLPlus and others can post thoughts/feelings/whishes and wants without the possibility of the thread being closed. This will also allow us as mentioned in this thread http://forum.joomla.org/index.php/topic ... 0795  to perform a service with the Core Dev team in an open manner.

2. 3PD's and others like us -- Join that forum/thread and be respectful yet insightful into how we can all help and better this situation. The worst thing to have is 1-2 people doing different approaches to a common problem that faces us all. WE all need to help the teams in this endeavor.

Thank you all for your time and energies and we look forward in helping in anyway possible.

Okay, I try to give an explanation as what is possible with ACLs.
ACLs are mainly for access control, but you can do a lot more if you don't see the definition of ACLs so strict. An ACL-rule consists of 4 parts: A thing that wants to get the access, another thing that says "If you choose me, you can do this or that", a third optional object that the first object wants the second object to perform on and at last the return-value if its allowed for the first object to do this. Here a few examples to clearify a bit:

First object: Hackwar, object of the section users
Second object: moderate, object of the section com_forum
Third object: Thread about ACL-stuff, object of the section "forum-threads"

If you send this to an ACL engine (thats based on the scheme introduced by phpGACL and used both by me, jaclplus and the original Joomla ACL) you will get an answer, that the user Hackwar is not allowed to moderate the Thread about ACL-stuff in the component com_forum. You have to create all these objects before you can say what they are allowed/not allowed to do. If you don't do so, you automatically get a false reply.

Second example:
First object: pagination, object of the section mambots
Second object: show, object of the section mambots
Third object: Article about peacefull coexistence, object of the section com_content

Lets suppose we don't want the pagination at the bottom of this article to be shown. In that case we would have earlier set the value to disallow and would get a false returned when we call the check-function.

The ACL itself does nothing more than telling you if a combination of two (or three) objects is defined as allowed or correct or whatever you want to call it. Everything else, if the pagination shows or the user can moderate the thread, is up to the following code. You could for example call the ACL-functions before a mambot is triggered and ask if this mambot should be triggered on this page or if it just should do nothing. The ACL just makes things like that easily configurable, but you would have to rely on the author of the component/core/mambot/module that he really uses these functions and the results that are coming out of this.

If you don't have to look onto performance, you could say that in every situation where you have several content-objects of the same type but which should be treated in different ways each, you could use ACL to see if this particular part of code should be executed or not.
It all sounds very abstract, but I don't really know how to explain it more clearly. I can just add more examples if you like...
Think of ACL like a big empty library. You have to first put books on the right shelves and then ACL can search for you in these shelves in these books and tell a surgeon for example that the point he wants to cut is ok. What the surgeon does with this information is a completely different matter. I hope its a bit more clear what ACL can do.


to 1.: I don't think this is necessary. Although a lot of people would like to have this function, a subforum for this special topic would be not very active. I doubt that there will be more than 20 threads per year. At the moment we have a few very active threads in this forum and I think its okay that way.

to 2.: I would really like to hear more opinions on this whole matter, especially from people that are not as technical as the people that have participated so far in this thread.

I would especially like to hear something on the caching of my solution. Without caching, the phpGACL engine is very slow, especially in comparison to JACLplus or the original Joomla ACL, but if you turn caching on, the speed should increase tremendously. My question would be, if you use caching in your current Joomla/Mambo installation and if you had any problems regarding this. I don't have much experience with caching and without a bit more work both on a benchmarking tool, the caching system and the installation procedure of my solution, I can't say how good/bad it will perform. This is a very critical thing, if the performance slows down to much by the API, my solution is dead like a run over squirrel....

In hope of many responses
Hackwar

any thoughts on integrating this with LDAP / Radius servers?

other posts:
http://forum.joomla.org/index.php/topic ... html  -LDAP stuff
http://forum.joomla.org/index.php/topic ... html  - multisite and radius???
http://www.joomlaya.com/forums/showthre ... site  - more of the same multisite/radius/ldap/acl stuff

You can create your own add-on to control the ACL-API. I don't think that there will be an LDAP / Radius / Passport / whatsoever-support in the coming versions, at least not with the standard package. An advanced ACL-support will first be introduced in Joomla 1.2 and full support should be included in Joomla 1.3 (I've got the hope that it gets done faster than that and will be completely ready in 1.2, but thats just a hope!) If you need LDAP-support for this, I suggest you write an add-on that uses the ACL-API and translates LDAP into calls for ACL. The functions that are currently available in the package I created will all be included in the final Joomla 1.3, ecxept probably those that are amrked by me as compatibility functions. They will most likely not be the same code, but they will take the same parameters and have the same return-values. You could start developing on this basis.

I read your other posts and as a suggestion from me: I would try to replace all queries of the user-table with a static table name. At the moment you have #__ in front of every table which gets replaced by the Joomla db-layer with the corresponding prefix. If you change that to something static and use this code with otherwise different prefixes, you should get a multisite-Joomla that shares the same user-db, but will have different rights (once ACL support is there. You could already use my package, but masterchief is working something out at the moment, which could introduce some changes.)

I use caching once my site is live and 99% complete. Is there a way to allow for caching if it is turned on. And not use it if it is not turned on?

BTW, I would use it.

I haven't looked into the caching of phpGACL more closely and can't answer your question right now, 'cause I've moved and don't have internet-access at home just yet. There is a switch that has to be set to activate caching in phpGACL. You can find it in the gacl.class.php. this caches only the acl-queries, not the whole page and I don't know if the caching engine used by Joomla is the same as it is in phpGACL.

I've read all of this thread, but I can't find where to download HACKWAR's ACL hack.  Is it available yet?  I'm messing around with JACLPlus right now, but it seems a bit lacking.  Right now, all I'm trying to do is have an "Anonymous" group for non-logged-in guests of the site, where some items are only available to them.  "Public" would be for "Anonymous" and "Registered" users.

You need to get Joomla 1.1 in order to test the hack.
Everything is here:
http://developer.joomla.org/integration ... m=exsy1002

Hi KipBond,
there is a link in a post from me way earlier, so here again, the latest thing from me. Be aware, still a proof-of-concept.

http://www.mutasound.de/gacl/acl_0_1_beta2.zip

This is for Joomla 1.0.4

Thanks, Hackwar.  The component didn't install though:



I'll try to run those queries manually to see if that helps.

I got it to work.  Had to change the database default character set to Latin.  Also, had to make some changes to the install script.  I'll email you those changes if you want?  Added some drop tables (for subsequent installs), removed some static table prefixes, ... just a little tidying up.    Thanks again!

I had static table-prefixes in it? I was pretty sure I had it all correct... Okay, now I see, its the last few entrys... I'm sorry, missed that.
Feel free to mail me your changes.

I have had a look at this patch, and once you figure out what AROs and AXOs are it's great.

What I want is to be able to say "Group G of users can submit content in category C".  Am I right in thinking that this patch is not sufficient to do that?
And that what I need to do is to hack com_content to treat each category as a different AXO?

--
Martin Orr

Yes, you're right. This hack just provides an API and emulates the old ACL-rules.

Tried to install this hack, got an error and now cannot log in to the admin interface.  I can log into the front end, so I know the login info is correct, but the admin login says "Incorrect Username, Password, or Access Level.  Please try again"

I've put back the original files in /html/includes/ and in /administrator/components/com_users/ - no joy.

Any ideas how I get back to where I can log in?

Thanks,

Liz

That is the problem with the gid. In the index.php it is checked if the gid of the user has a special value, but because the groups have been rewritten and can change at any time now, the gid (=group-id) is not the hardcoded one that is expected. You can either recreate your old group-ids (which can be found in the SQL-entrys of the installation script) or change the gid-part in the index.php to fit the current ones.

Thanks, Hackwar.  I decided to just start from scratch with 1.0.5 - I've done a lot of install, test, uninstall lately to find components I want to keep and that's left some stuff behind, so I figured it's better to start clean :-)

Please keep up the good work.  I agree with those who say this feature (more flexible access control) is *way* overdue!

Thanks,

Liz

And when you look at the Roadmap for 1.1 there is no sign of ACL coming our way. This feature is still a year away (1.2). A real shame =(

So, a few news on the topic. I hope someone still follows this...

1. I dropped work on integrating ACL into Joomla 1.0.x. If anybody needs it really bad and can't wait till Joomla 1.1 is released or some time around supposedly beginning of march, he or she can use the component I provided in the thread. You however have to work out the kinks yourself. If you want to try it, pm me and I'll give you a few hints.

2. I'm advancing in creating a series of components and core-hacks to implement ACL into Joomla 1.1. Its going to be at least 3 components and one major core-hack. To implement this properly, a LOT of files have to be changed. The problem is, that over the years, several ways of authentication have been implemented, that all make me shudder in fear when I think about replacing them with one solid solution. (For the experts: Some check against statich group-ids, some check for certain group-names, some get the gid based on the group-name and last but not least, there are some that use the current ACL-API) The solution will be a group-manager, a user manager and an access rule manager. I'm pretty far with the group-manager and I have certain ideas on the user manager, but I'm stuck with the access-rule manager. Later more on that. The core hack will be extremely massive, allmost everything to authenticate a user has to be edited and to implement content-based access checks, a lot of components have to be edited to save entrys for this in the ACL-sub-system. Last but not least even the installer has to be overhauled to enable components to automatically insert objects for them in the system. Because of that, I've suggested making it a seperate release. I don't have an answer up to now and quite frankly, I don't expect a positive one. ACL was "allways" supposed to be released in 1.2, which is still some way to go.

3. To not depress you any further: Andrew wanted to publish the component and hacks as an official add-on, like Joomfish will be. To make handling of this easier, this will most likely only contain stage 1 of the ACL implementation as described in the roadmap. The real extend of the implementation is not decided as to now.

4. Now I'm coming to the part I need your help. As I said I'm somewhat stuck with the access-rule-manager, which means, I don't knoe how to design the interface. So far I've got three ideas.

  1. I use the generic admin-interface of phpGACL. I could simplify it a bit, but not much. Personnaly, I don't think the average user will be able to handle it.
  2. I use a very complex form, that in the first part collects the users, than allows to choose with check-boxes to which components, etc. this should apply and at last pops up with boxes to choose the content this applies to. Makes the coding very complicated and its not easier than the generic interface. From an artists point of view, it wouldn't look nice either, which means creating rules would be a mess and they wouldn't be so extremely efficient as they could be.
  3. I use something similar to the generic admin-interface, but splice it into several pages. On the first page you would set the user(-groups) and the different values of the rule, in the second you would choose the components this applies to and in the third and final, you would have the content to choose from. Not very fast, but in my eyes a very good way to get Joe User to not kill the app.  Would be something like an assistent.

At the moment I have no idea how to proceed on this one. Somehow all these approaches don't feel right to me and I keep thinking about other ways to do this, but I can't come up with something new. I hope to hear some comments from you about this. I hope especially the few who have seen the generic interface of my component for Joomla 1.0.x can say something about it. One word before you start writing: I really don't like the idea of big tables and to click activation symbols for function/user-pairs, like I have seen in a screenshot of JBAM. We have the nice possibility to create 3-D rules, where users, components and content are involved and I don't think its a good way to "reduce" this on two dimensions. I also think its not very user friendly.
Apart from that, please let me hear your opinions and suggestions.

Since I have to do a bit none-Joomla stuff in the real world, I can't work on this fulltime before february 11., but after that, it should get done pretty quick.
Thanks for your patience and your kind words.

Hackwar