[15]Access Management in Joomla! 1.6

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Better ACL permissions – based on groups or users?

Post by petoroth » Thu Mar 06, 2008 7:17 pm

Better ACL permissions.zip
Introduction
In this topic I would like to contribute to the discussion about desirable improvement of ACL permissions in Joomla 1.6. At first I have to say I’m not a programmer I only want to point out my requirements, expectations and possibility I have about new version of Joomla.
Sorry of my English, I don´t come from an English-speaking country. I´m a Slovak.

Scope
Many features are proposed:
  • to determine what can the user see and use,
  • to determine who, what, where + how and for whom can manage items,
  • ACL permissions and ruled should be based on users
  • horizontal improvement, extension of groups (I’ve named it TEAMS),
  • content (articles, categories, sections) and items in other component or modules address only to specific teams,
  • the present Groups (Author – Super Administrator) substitute for Roles, Functions,
  • new components to administer teams (groups), users and their information,
  • improvement of the component User Manager,
  • changes of the users management should be in Joomla-core to cooperate with other components.
Situation
Joomla 1.0 and 1.5 have limited possibility to assign items (articles, items in Calendar, photos in Gallery) to specific group of users. Some components or plugins in extension´s category Group Access (http://extensions.joomla.org/index.php? ... &Itemid=35) were created to improve access permissions, but there were problems with them:
  • Many of them were commercial,
  • Some of them were core hacks (JACL +), and therefore was problem with upgrade Joomla to newer versions,
  • Their co-operation with 3rd parties component were limited,
  • They controlled only some parts of web-content (menu, section, category, article items...).
In some forums, e.g.: I’ve noticed desire for better ACL permissions (maybe with improvement of PHPGACL in Joomla) because the 3 access levels: Public, Registered, Special are not at all enough. In my opinion the awaited improvement of ACL or addition of groups shouldn´t improve the access permissions vertically (from Registered to Super Admin Users), but horizontally (Group A, B, C.... with equivalent access levels).

Why is it so needful?
I give two very common examples:
1. Example - Very good structured school website...
The Webmaster of this school can publish public items (articles, items in Calendar, photos in gallery...) for all users (headmaster, teachers, students, student’s parents...). But some items he wants to address only to teachers, or some classes. Or teachers would address items only to their students in some classes... For this reason I could use JACL+ for example, although it isn’t the best solution.
But in some classes there are some very creative students that want to publish their own items (common class newspaper). Of course Webmaster doesn’t allow them to publish their items for all users at school; they can publish items only for their class or classes in the same year, for example.
For this reason they can’t have roles of contributor as: Author, Editor or Publisher for everything, because nobody and nothing (except their conscience) can stop them to publish their items for all users.

2. Example – Very large web site
In a very large web site is very common to divide responsibility for the web content. E.g. first author (editor or publisher) is responsible for the section Sport, another for Culture... It means that the first author can manage items only in his section Sport and doesn’t have the access to manage items in other sections.

From these two examples follow partial conclusions:
  1. It doesn´t suffice to control who can or should SEE items, USE components or modules in front-end environment. It is very necessary to control Who? What? Where + How? and For whom? (these interrogatives I will explain later) can PUBLISH items, although only for his group.
  2. A user can belong to more groups, in the first group he can be only the user, but in the second group he can publish items only for his group for example.
  3. It would be complicated to create so many groups with their access levels I have users, even more groups with specific access levels for one user.
For these reasons I don’t think the ACL permissions and rights are necessary only for groups, I think the ACL permissions and rights are mostly very necessary for (some) users.
Why for some users only? Because many users remain in the biggest group: Registered without any permission to add, edit... anything and anywhere...

What to do?
1. Step – What can the user SEE + USE?
There are some user-groups in current versions of Joomla 1.0.x and 1.5x, but it is necessary to assign some items to specific groups of users. I’ve named these specific groups TEAMs to understand the difference between the group and the team (specific group). By the way I think the present expression GROUP (Pic1) isn’t right I would use the expression FUNCTION or ROLE, because “groups” as author, editor, publisher, manager or administrator are rather functions or roles than authentic groups.
The Team should be a “group” of users which has although primary the permissions as group Registered, but Team should associate users that should SEE the same content items and USE components or modules that are invisible for unregistered users, users in Group Registered or in other Teams. Basically it is the horizontal extension of groups (roles) I’ve mentioned in the introduction.
To administer teams it is very necessary a new component: TEAM MANAGER in the back-end. In this component you can create many TEAMs and assign them to specific access level. For example: When you create TEAM A, automatically is created access level_teamA.
Another useful component both in the back-end and in the front-end is a USER LIST. Thanks to this component a user could see other users in the same team(s), their information (address, mail, phone number...), send PM, or see if they are log on... Maybe the Community Builder is usable for this solution.
Very necessary is to improve the USER MANAGER component. I would put under the field Group a new multi-selective field named Team. In this field the administrator could assign a user to one or more teams. When a user belongs to none team, this field keeps free and the user sees only items for common access levels as public or registered.
user.jpg
Thanks to these new steps Administrator could bring under control what users can SEE or USE.
In my opinion these changes are suitable for these sites too, where users have to pay to be a member of Team: Bronze Member, Silver Member, Gold Member... because you can easy determine the content for each Team.
When you assign users to teams and each team has its own access level, you can easy create content suitable for one, two or more teams. I give a very common example with the com_content:
You could set access level in the multi-selective box for the section, for the category or for the article item. Of course, the category inherits the access permissions and rules from the section; the article item inherits it from the category... So, let´s say, we have 4 access levels A, B, C, D. When you set the access permissions in the section only for access level A, B, C, then when you create a new category, you can use only these 3 access levels and the fourth access level D is invisible in this box.
It would be great when these desirable changes in Joomla-core cooperate with other components, e.g.: Pools, Calendars, Galleries, Forums, Chats, Comments, Blogs, Download Managers (DOCMan) or E-markets (VirtueMart) or modules (Menu).

2. Step – Who, what, where + how and for whom can MANAGE items?
Another very common problem is to determine WHO, WHAT, WERE+HOW and FOR WHOM can manage (add, edit, delete, move...) items. These five interrogatives hide conditions for adding, editing, deleting... an item. I will explain it:
  • WHO? – a user from all users,
  • WHAT? – means in which component or module can user add an item, e.g. com_content, mod_menu,
  • WHERE? – it is needful in large sites with many sections and categories in com_content for example, to determine in which section or category can the user (author, editor or publisher) add an item.
  • HOW? – user who contributes to the web content can be in section sport AUTHOR, but in another section culture PUBLISHER for example. Therefore I would use four possibilities to determine permissions of contribution: NONE – no access to contribute, AUTHOR – contributes as common Author, EDITOR – as Editor and PUBLISHER – as Publisher. For this reason I would maybe take away the Author, Editor and Publisher from the Groups and use them as role or function in this structured table.
    Evidently the back-end users (MANAGER, ADMINISTRATOR) doesn´t need these rules, they can contribute, manage items everywhere without any limit.
  • FOR WHOM? – some items should be address only to some access_levels. Here you can define, for whom this contributor can write items. For example there are set 4 access levels (to see) in a section then you can choose only among these 4 access levels when you want to add an article to this section. Of course the contributor can add an item only for these access levels (relevant to user groups: Public, Registered or Teams) whose member he is!
When there are two or three various user-functions for categories, the section inherits the most important one. E.g. there are in the section Sport three categories and each category has a different function (News-Author, Basketball-Publisher and Football-Editor). The section Sport inherits the important one it is the Publisher. Access levels (For whom?) work comparable with Function (How?).
Let’s see how it can work... I remind once again I’m not a programmer, for that reason I only show what it can look like, how it can work, but I don’t know how it must be programmed! To answer and explain these five interrogatives I would use a well-structured table, which can be an organic part of user component to manage rules and permissions of all components and modules or a stand-alone component or small part of each component....
table_permissions.jpg
Conclusions
It is very necessary the improvements of the ACL permissions and rights. I don’t think the ACL permissions and rights are necessary only for groups, I think the ACL permissions and rights are mostly very necessary for (some) users. To determine what can the user see and use you can manage it with many teams (groups) however when you have to set who, what, where + how and for whom can manage items you have to give rights to the users.
In my opinion the present groups, except Public and Registered, are rather functions or roles than authentic groups. There are very needed some new components to administer teams (groups), users and their information.
These desirable improvements have to change the Joomla-core to allow cooperation with other components.
Better ACL permissions.zip
You do not have the required permissions to view the files attached to this post.
Last edited by petoroth on Mon Mar 10, 2008 1:04 pm, edited 1 time in total.

nightlrd
Joomla! Apprentice
Joomla! Apprentice
Posts: 49
Joined: Wed Aug 22, 2007 10:13 pm
Location: Los Angeles
Contact:

Re: Better ACL permissions – based on groups or users?

Post by nightlrd » Thu Mar 06, 2008 10:41 pm

I like your article. I am one of the people that am praying for better ACL. For me the, the dream situaltion would actually be if they implimented something like Drupals ACL system. Honestly, the only thing that holds me back from setting a Drupal site for the org I work for is that I love the rest of Joomla (the ease of use and so on). Plus I need to look at the learning curve adnd burden I would be placing on the person that I left it to if I ever leave. :D

Realy, Joomla with Drupals ACL would be perfect IMHO. Just my 2 cents ;D

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: More user control

Post by petoroth » Fri Mar 07, 2008 7:25 pm

I agree, however there are more features that should improve.
You can read my topic: http://forum.joomla.org/viewtopic.php?f=500&t=272650

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Sat Mar 08, 2008 9:56 pm

Now this is certainly the best post I have ever read in this forum!

I agree entirely with the logic, the question is how do we do it?

Also I have to apologize for not writing correct English, Swedish is my native language.

My own problem is simpler. I just need to control who is able to publish within what categories. I propose the following solution:

1. One more table is needed, called _permissions, to connect users and categories. Contents of this table are controlled from the backend in menu choice "users", I am focusing on publishing permissions but let's assume that his table has five columns. One for user ID:s, one for category ID:s, three for ticking authoring, editing and publishing permissions respectivly per category ID. With thousands of users and hundreds of categories this will not be a small table, but that is not really a problem.

2. A change in the code used by 3PD and others so the various editors and all other program modules do not allow authoring, editing and publishing except within the categories that are ticked off in the _permissions table.

Example: When connecting modules to menu items it is easy and useful to be able to decide what modules will be published for what menu items. I would certainly assume that the same technique could be used to connect users to categories in the backend via the same kind of dropdown menu.

Could this easily be implemented in the authorization.php module in libraries/joomla/user ? Anyway, whenever permissions are checked the only thing that is needed is to add this new table to the algorithm.

In the various editors it would then (after implementing the changes) be impossible to save an article in sections/categories that are not registered as allowed. And of course it would be impossible even to access articles i "forbidden" categories to author, edit or publish them.
Last edited by the_real_svempa on Sun Mar 09, 2008 8:51 am, edited 1 time in total.

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Better ACL permissions – based on groups or users?

Post by petoroth » Sun Mar 09, 2008 8:40 am

I´m very glad that you enjoy my article. I have written what it can look like, how can it work however I don´t know to program it.
I have tried the components:
cACL http://extensions.joomla.org/component/ ... Itemid,35/ for J!1.0
cACL MVC http://extensions.joomla.org/component/ ... Itemid,35/ for J!1.5
It looks very good and solves my second question: Who, what, where + how and for whom can MANAGE items? at 80%,
however it is a core-hack and a commercial component.
It can be certainly an inspiration for the member of core-group.
Last edited by petoroth on Mon Mar 10, 2008 1:05 pm, edited 2 times in total.

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Sun Mar 09, 2008 1:03 pm

Going back to my basic problem of assigning user permissions (authoring, editing, publishing) not generally for all categories to the user, but for selected categories for each user, I have looked a little in the database and in the code. Since the logic I would like to see implemented is very similar to the logic for assigning modules to all menu items or to selected menu items I have tried to find out how this is handled in Joomla!.

There is a database table called #__modules menu that relates modules to menu items. If a module is related only to menu item 0 (zero) this obviously means it is published for all menu items. If a module is not related to any menu item it will never be published (an assumption I make), and if there exists several rows in the table for the module, each relating the module to a specific menu item, the module will be published for only these menu items.

Each time a module is created or edited it must be saved as the final step, and in the program controller.php in /administrator/components/com_modules a function "save" is defined where the needed rows are inserted in the table #__modules_menu.

This is exactly the way I can see a basic permission system be implemented. Every time a category is created or edited the administrator can be presented with a dropdown list of all users with authoring, editing or publishing permissions. Usually the number of such users is not too large to handle, in my own case never more than 5-20 users, a further evolution would be to handle groups of users the same way. Not necessary in my own case of course. Choosing a user from the list would mean giving this user the permissions he already is assigned for this category. Doing it this way would mean that the needed table (let's call it #__users_category) would have exactly the same structure as #__modules_menu.

When saving the category almost the same code as in the program controller.php I referred to earlier can be used. Some housekeeping is also needed, rows may have to be deleted from the table when a category is deleted, but that does not seem to hard to to.

The last step is to include some new code in the functions provided for 3PD and others who write editors and such where a list of available categories are presented to the user when writing/editing/publishing an article.

Any comments on this?

User avatar
webamoeba
Joomla! Explorer
Joomla! Explorer
Posts: 433
Joined: Fri Sep 16, 2005 9:13 am
Contact:

Re: Better ACL permissions – based on groups or users?

Post by webamoeba » Mon Mar 10, 2008 11:44 pm

the_real_svempa wrote:This is exactly the way I can see a basic permission system be implemented.
ewww yuck. ;) lol - This is really not a viable solution. A drop down list of all users! blimey, that in itself would be completely unmanageable in sites with a large number of users.

On a far more positive note, I agree that access-control is an important issue. I remember back when I discovered Joomla! (at the time it was Mambo) and thinking how important this was and that it needed addressing. Sadly X years on it has still not been fully realised.

OK, a quick bit of background, Joomla! uses PHP GACL, sort of, or rather, in a very limited way. PHP GACL consists of four `concepts`:

ACL - Access Control List - Permissions list for an object
ACO - Access Control Object - Object to deny or allow access to
AXO - Access eXtension Object - Extended object to deny or allow access to
ARO - Access Request Object - Object requesting access

To explain this a bit better I'll grab a quote from a Joomla! book:
In phpGACL, permissions are given to ARO groups and AROs, to access ACOs and AXOs. In Joomla! we only give permissions to ARO groups, and Joomla! users can only be a member of one group, whereas in phpGACL AROs can be members of multiple groups

These differences between Joomla! and phpGACL are due to one major factor. In phpGACL when we check permissions, we ask the question ‘does ARO X have access to ACO Y?’. In Joomla! we ask the question ‘does ARO group X have access to ACO Y?’. The way in which we assign permissions in Joomla! will be altered in the future to use the same principals as phpGACL.
Fully implementing PHP GACL fully is a major issue, mainly because of backwards compatibility. J! 1.5 has made some additional contributions to the setup that make some big differences, it's just that its all pretty invisible to the end user and admins. For example, the MVC framework includes permission checking and the JUser class includes a handy authorize() method. Also the three groups public, registered, special, I think have technically been deprecated...?

OK, I'm getting a bit bogged down in the technicalities, so rather than bore us all to death (myself included) let's address the real issue here. Not 'we want better access-control', but 'What are the ramifications of implementing PHP GACL fully on both the J! core and third party extensions, and what is the best way to deal with the transition period'.

I remember some time ago, I saw something stating that this would be addressed in J! 2... but I'm not sure if I just imagined that ;) lol.

Let_Me_Be
Joomla! Apprentice
Joomla! Apprentice
Posts: 14
Joined: Mon Mar 03, 2008 7:25 pm
Location: Czech Republic
Contact:

Re: Better ACL permissions – based on groups or users?

Post by Let_Me_Be » Tue Mar 11, 2008 3:26 am

I must say that ACL is the thing that I miss the most. Yes there are some commercial components, but they are encrypted, don't work with other components and create a fatal vendor lock-in.

The thing you completely missed are subscriptions (time limited access rights), this is really needed even for the school example you posted. An extended version of school site is an e-learning site. I know that there are specialized CMS for e-learning sites, but from the point of content management I really didn't like what I saw.

It would be nice to create a backend for the access rights (so there won't be the need to hack the core), and maybe leave the front-end functionality outside of joomla (for most people admin->writer->registered->anonymous is enough).

The best access rights managements systems i know work with roles. Role = description of permissions. Users can have several roles. Add a time limits (user has a role from given time to given time) and we have everything we need. The concept of roles gives a huge simplicity, because it allows the admin to specify short and concrete roles with few permissions/restrictions.

User avatar
webamoeba
Joomla! Explorer
Joomla! Explorer
Posts: 433
Joined: Fri Sep 16, 2005 9:13 am
Contact:

Re: Better ACL permissions – based on groups or users?

Post by webamoeba » Tue Mar 11, 2008 12:59 pm

Let_Me_Be wrote:time limited access rights
I think this is a separate issue. This would not be part of the GACL implementation, and it would only apply to users that login via the `Authentication - Joomla!` plugin.

However, whilst we're discussing this, it might be nice to include `grace logins`, and `password expiry` ?

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Better ACL permissions – based on groups or users?

Post by petoroth » Tue Mar 11, 2008 2:35 pm

webamoeba wrote:
Let_Me_Be wrote:time limited access rights
I think this is a separate issue. This would not be part of the GACL implementation, and it would only apply to users that login via the `Authentication - Joomla!` plugin.
I think too. I have to admit I´ve forgotten that subscriptions are very needed. For me maybe not. But I think it could be another component or anythinh else. This is pettiness for me.
The most important is to rule who can add an article, an item, where and for whom...

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Tue Mar 11, 2008 2:36 pm

ewww yuck. ;) lol - This is really not a viable solution. A drop down list of all users! blimey, that in itself would be completely unmanageable in sites with a large number of users.
webamoeba,

Pls read more carefully so you can avoid replying out of context. Naturally a big site with thousands of users could not use drop down lists of ALL users. But that is not what I wanted, I am only interested in the small number of users who are publishers. And they do not run into the thousands per site, not even the hundreds usually. On smaller sites, like mine and many, many others, we are talking of perhaps 10 users who need to have permissions to publish 2-3 categories each of perhaps a total number of 30 categories.

You are also forgetting something important. To have a working ACL you absolutely need to relate users to content, it is central to the whole concept. The next question is then WHICH users need to be connected to WHAT content. The answer to that decides the magnitude of the obvious problem to manage these connections. If you can limit the number of users and/or limit the number of categories that are affected by the ACL system you make the management task easier. For really large sites it may be necessary to give permissions to groups of users instead of individuals, but the same basic methods can still be used. Possibly a special backend tool would need to be constructed to handle really large sites.

Now I keep using the term "categories", in the future the way content is organized may change to include "subcategories" or maybe some kind of many-to-many relationship instead of an hierarchical system like we have now. But that is beside the point, it is still necessary to relate users to content if you want to have an ACL. In this context I prefer to use the existing content structure as a discussion base, I believe it makes my arguments easier to understand.

OK, back to basics. Previously I sketched a necessary two column table called #__users_category, used to relate users to categories. Let's work a little more on this concept. Add a "permissions" column to the table to indicate exactly what permissions this user (or group of users, possibly) has for a particular category. Postulate the following:

1. If a user is not in the table, or if he/she is connected to category id zero, the user is not in the ACL system and everything works as before.
2. If a user is related to at least one category he/she is in the ACL system, and the permissions column can be used to indicate precisely what the user can do with this content. Let us still use the author, editor, publisher system where each higer level includes all lower levels. This means that a user in the ACL may view the same content as all registered users, but is permitted to author/edit/publish ONLY within the categories he/she is connected to.
3. If you wish to include viewing permissions in the ACL system that is also possible. In such a case the user would only have viewing access to the categories he/she is explicitly connected to.
4. It would be entirely possible to give the users in the ACL system viewing permissions for certain categories, authoring permissions for other categories (which of course would include viewing permissions), editing permissions for still other categories (which would include viewing and authoring) and so on.

All this functionality using just one extra table, and (I would assume) not very much coding work to do. Did a little php coding about seven years ago, am thinking of brushing up the small skills I aquired (I have 40+ years of coding experience, but mostly in VERY obsolete programming languages...) and see what I can do myself. I installed JoomlaPC recently, that seems like a good start :-)!

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Better ACL permissions – based on groups or users?

Post by petoroth » Tue Mar 11, 2008 3:10 pm

I agree with the_real_svempa
Basically You wrote the same what I´ve tried to explain in my contribution.
I agree, when you have a big site with 1000 users, only some of them, maybe 50 users, can contribute to the site.
However I think the com_content with his sections and categories rules in still not enough, it is needed to make bigger core-changes, in order to cooperate with all other components and moduls.

User avatar
webamoeba
Joomla! Explorer
Joomla! Explorer
Posts: 433
Joined: Fri Sep 16, 2005 9:13 am
Contact:

Re: Better ACL permissions – based on groups or users?

Post by webamoeba » Wed Mar 12, 2008 4:20 pm

Hi the_real_svempa, sorry if my initial reaction seemed a little offensive.

Reading through your latest post, I have some major concerns about what you are suggesting. The phpGACL stuff is sitting in the wings just waiting to be implemented fully, adding your proposed solution at this stage would just add another layer backwards compatibility issues when it came to a true GACL implementation. I would definitely not be inclined to use the "old skool" author, editor, publisher groups. As I said earlier, I believe these are technically considered to be deprecated.

Your also talking specifically about the content component, but the issue is way more far reaching than this.

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Wed Mar 12, 2008 5:51 pm

webamoeba,

No problem, absolutely no offense taken. I am sure that you are acting in the Joomla! community's best interest, and I certainly hope that the ACL you describe will be implemented. But in a situation where many things need to be done and everything is up to the relatively few experienced Joomla! developers who do an admirable job, but they also have a life to live and probably an ordinary career to look after, the question is when?

It is only natural that a few of us get a bit impatient, this does not mean we are dissatisfied with what we already have been provided with completely free and gratis, rather the opposite. We see the enormous potential, we try to talk others into using Joomla! as a base for their websites, and want to learn what can be done using all the standard functions. And then we of course sift through all the extensions that are provided by other Joomla! enthusiasts to get even more functionality, and try to integrate them into our sites (which is not always entirely painless).

By the way, I looked into JUGA hoping to solve my problems using that extension, but soon found that was not possible. So there I am, my needs are immediate and while phpGACL may be in the wings nobody knows exactly when it will be available. In one year? Two?

My admiration for you Joomla! experts has risen to new levels after I have tried to familiarize myself with the framework, how the system is built and how to make a new component or module. However, I still believe I could implement my own simple "Joomla! hack" with just a small number of changes. The table relating users to categories I need can (to start with, anyway) in my case be built and maintained using phpMyAdmin, the other changes are:

1. A php function that checks the database to see if the current user has (publishing) permissions for a category.
2. A call to this function in the checkout code, so only users with publishing permissions for the existing category can access an existing article.
3. A call to this function in the "save new article" code, so only those with publishing permissions for the chosen category can save a new article.

This would give me the functionality I need, at least that is what I believe after reading a lot of Joomla! code :-)! It is not the perfect system, publishers with limited permissions would still SEE categories they do not have permissions for, and they would not get an error message until they actually try to go outside what they are allowed to do. But it would work for me and for my users, and it would not be difficult to reimplement in future releases of Joomla - I believe there will be a few of those before phpGACL becomes a reality...

VanCrey
Joomla! Apprentice
Joomla! Apprentice
Posts: 22
Joined: Mon Dec 17, 2007 10:57 pm

Re: Better ACL permissions – based on groups or users?

Post by VanCrey » Wed Mar 12, 2008 10:54 pm

Hello Petoroth,

as requested, I went through your specification and found following points

1. Assignment of roles to specific users makes not much sense, if you consider the amount of complexity. It's probably nice for special situations, but I think we should move this requirements to a secondary point until the Joomla community gained some experiences by working more with user groups. It would be already a nice step to allow the creation of unlimited user groups, which can be assigend to several users. This also includes, that a user can be member of a more then only one single group.

2.I agree that some basic Joomla features should have more differentiated, but we have to split this "authorization" checks into 3 stages

a) The first "simple" authorization check is for the joomla framework itself, which can easily encapsulate the rendering of components, modules and menu-items by doing a ACL check. All informations are alread available, there is only less then 10 lines of code neccessary to do the that job. If the joomla framework would fire a suitable event before and after the rendering of modules and components, we can place the whole code into a plugin!

b) The next stage tries to get a basic authorization INTO the bahaviour of components, without touching the code. It's a basic mechanism to evaluate the "default" request parameter like "option", "task", "view" and "controller". A "simple" plugin implementation evaluates the parameters in the request and makes automaticly a authorization check. This check requires, that someone defines all used tasks into a list - which allow us to write a ACL Managment component. This can be a simple XML file and it can be delivered separatly or written independly, if missing.

c) We have already the general access check to our module or component and we also have a control of calling specific tasks, but last but not least, we need also a way to allow to manage/control specific elements which are provided by a component. In this case, we can not clearly find out which entity is requested especially if there are different types. In this case, the developer of the extension itself has to do the first time some code changes in his extension - and - its not so much as the most people expect now. It's probably only the call of the JUser::authorize method at the right time . But what's about the control component? No worries, I come back to this point some lines later

3. One problem is the existing limited authorization check using the "access" field for "public", "registered", and "special" and the direct assignment of specific table entrys to one single group by using a colum like "gid". This part needs probably a small refectoring, because it could clash/overlap with a existing ACL farmework integration. The "access" Part can be probably placed on top of an ACL framework, which allows to assign specific user groups to "registered" and "special".

4. I do not want to talk about new specifc user groups like as suggested "Team Manager", "User Manager", because that's does not chance anything about our general problem to be unable to individual define new groups. "Silver", "Gold Member",... that's should be a customizing issue - also the combination such as that a user is "Author" and "Manager", but not a "Publisher".


Ok, now to the more practical stuff

After reviewing the current Joomla situation and also several prototype experiements, I finally came to a conclusing for covering everything without redefining the whole Joomla application. Everything what I wrote bevore is based on my experiences writing a first "free" protoype for an ACL support.

1. There is one single component, which provides a easy to use interface for managing / control the used ACL framework behind (PHPGACL).
2. I figured out the best way to store and separate different ruleset into the PHPGACL DB.

a) One or more several different basic ACL rules are definied by an developer, which brings together a Objecttype that we want to control AND the way we want to get access like edit, view, add,...
b) The ACL Ruleset are fixed and only automaticly integrated through evaluating a XML file.
c) The Objecttype (compareable to a user group) that we want to manage and the way we want to do is always fix and can never be changed through a managment Tool.

Example:

ACL Rule "Publish Content" brings together the Objecttype "Content" AND the way/task "publish".

This rule can now be assigned to User Groups and Users (what I do not really suggest).

d) Furthermore we need a way to assing individual entries of an Objecttype such as a "Article" of the type "Content". This is only possible by using a existing ACL rule as template such as "Publish Content" and create several individual clones from them, which brings together individual User-Groups/Users, a fixed defined task and a individual entry of a specific fixed defined Objecttype like "Content".

e) We need now a way to place everything into a common definition file, which automaticly creates the basic structure that we can instructed later by using our ACL managment extension. This file is based on XML and I already worked out a first proposal, that I attached to this post.

This file allows following

- Defining different new Objecttypes like "Content"
- Dynamic assigmnet by providing a SQL file to locate all entries, which will be automaticly appended to a Objecttype - and later listed into a confortable frontend.
- Defining a list of tasks, which are available
- Defining additonal user groups
- and finally the Ruleset, which brings together everything. It's also possible to initial assign existing user groups to a rule like Rule "Change Preferences" for "Administrator" and "Manager".

f) And finally we also need something to lose not the overview into our DB, so that we know which rules is owend by which extension. We use a way which is called as "namespaces" by appending automaticly the owner-id of each piece of information in our DB in front of the value such as for Object types "com_content:articles" or tasks "com_content:publish".

Can you remember the Point 2c) ? Hey, we are able to define rules, object types and also automaticly assign entries from unknown (from our point of view) extensions by executing a simple provided SQL command. We can manage all ACL Rules and only in the case of 2c), the developer has to do a simple JUser:authorize Method call!

Furthermore, we provide a simple Upload feature, which allows to upload independently ACL XML definition file. This allwos a Administrator to get some ACL control into a third party extension, which does not already support itself our ACL Managment tool.

I already wrote partially the ACL Managment tool and the ACL loader mechanism to handle the attached ACL file. Everything is 100% sophisticated, so that we do not get any suprises - this also includes the replacement of the available PHPGACL control frontend, which is awful. Everything follows the idea "Keep it simple and stupid" or was it "Keep it simple, stupid" : o ) - without loosing functionality

Cheers,

Andreas

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Thu Mar 13, 2008 9:53 am

The basic publisher control system I put forward a few posts ago is now implemented. Seems to work very well, but of course more testing is needed.

The basis for the system is the table previously described, #__user_category, that creates relations between users and categories. User id in the first column, category id in the second, both as INT.

The logic is that if the user id exists in this table he/she is controlled by the "Detailed Publisher Permissions" system as I call it. However, if the user is NOT in the table OR is connected to category id 0 (zero), everything works the same as before. If the user IS in the table and NOT connected to category id 0 (zero) he/she is limited to editing and publishing articles within the categories that the user id is connected to.

The code hack is limited to controller.php in /components/com_content/ and consists of a function, added at the very end of the existing code:

Code: Select all

/**
     *  Get user - category connection for DPP
     *
     */
    function get_user_category($cat_id)
	{
		$db =& JFactory::getDBO();
		$user	= & JFactory::getUser();
		$user_id = $user->get('id');
        $number = 0;
		$query = 'SELECT g.category_id'
			. ' FROM #__user_category AS g'	
			. ' WHERE g.user_id=' .$user_id;		
		$db->setQuery($query);
		$cids = $db->loadResultArray();
		foreach ($cids as $category_id)
			{
			$number++;
			if ($category_id == $cat_id || $category_id == 0) return $number;
			}
		if ($number == 0)return $number; else return -1;
	} 
and two very similar snippets of code, the first inserted in the "edit" function just before the call to checkout:

Code: Select all

//Check detailed publishing permissions
        $cat_id = $model->get('catid');
		$pp = get_user_category ($cat_id);
		if ($pp < 0) {
		    $msg = JText::_( 'No editing permissions for this category' );
		    $this->setRedirect(JRoute::_('index.php?view=article&id='.$model->get('id'), false), $msg);
		    return;
             }
the second inserted in the "save" function just before the comment "//perform access checks" :

Code: Select all

//Check detailed publishing permissions
		$cat_id = $post ['catid'];
		$pp = get_user_category ($cat_id);
		if ($pp < 0) {
		    $msg = JText::_( 'No publishing permissions for this category' );
		    $link = JRequest::getString('referer', JURI::base(), 'post');
		    $this->setRedirect($link, $msg);
		    return;
             }
Pls excuse all the rough coding, I am an ancient Cobol programmer who needs to have the PHP syntax manual beside me, and who is totally ignorant of the inner workings of Joomla!. But it seems to work the way I want it to, let's call it a alpha 0.1 release. I have vague plans for some instrument to handle the table maintenance, some php code in a wrapper perhaps, but that will come later. The same simple technique could also be used for a Detailed Viewer Permissions system of course, but I do not need that so I feel no urge to do something about it.

Now I do not want to disturb the plans for a REAL ACL, I just want something that I can use NOW. I will be very happy to scratch my own system and start using phpGACL when the time comes. Hopefully I have not irritated my betters in the Joomla! developers community by carelessly and brutally invading their code.

The DPP system is now implemented at http://www.nodingegolf.se, logon with Testare/test1 or Testare2/test2 if you want to see how it works.
Last edited by the_real_svempa on Thu Mar 13, 2008 10:41 pm, edited 1 time in total.

User avatar
newart
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3177
Joined: Fri Sep 02, 2005 10:06 am
Location: Solar system - Earth - European Union

Re: Better ACL permissions – based on groups or users?

Post by newart » Thu Mar 13, 2008 6:06 pm

I cannot add anything useful else at this Great white paper, I'm not so expert for proposing a better solution. I post here only for pointing this idea out, please don't miss the train! I don't know, sorry, what's the best solution ever but We do know that a solution for ACL is important for a smarter joomla.

Indeed there are sundry areas in which joomla needs an improvement suc as ACL and content categorization...

PS. this post is for supporting a better ACL.
former Q&T WorkGroup Joomla member - Italian Translation Team Member

isarg
Joomla! Intern
Joomla! Intern
Posts: 77
Joined: Sun Jun 11, 2006 1:57 pm

Re: Better ACL permissions – based on groups or users?

Post by isarg » Fri Mar 14, 2008 7:52 am

newart wrote:I cannot add anything useful else at this Great white paper, I'm not so expert for proposing a better solution. I post here only for pointing this idea out, please don't miss the train! I don't know, sorry, what's the best solution ever but We do know that a solution for ACL is important for a smarter joomla.

Indeed there are sundry areas in which joomla needs an improvement suc as ACL and content categorization...

PS. this post is for supporting a better ACL.

The key here is not only additional access control levels but workflow. I am not sure I'd classify Joomla as a CMS.

The level of granularity on the access levels itself being less than a handful for users/admin functions is silly. While I am far from intimate with Joomla's code I can only assume that the software does compare user access levels to module/component etc. accepted levels, so... there is no reason a "core" limitation should be placed upon these.

More so however to me is the issue of workflow. CMS by nature as a term is to manage content and thus workflow. Some admins may be charged with system admin cleanup and function. Others are authors submitting content to an editor who may approve or send it back for further work. An editor passes documents to your sites graphics parties to pretty it up and add in what need be added. They pass it to the publisher who says, "ok" who in turn passes it to your Joomla content admin who gets it live. You may have people charged with any number of duties from archival, files management, syndication to a blogMaster.

Most certainly tough to cover all bases.

Joomla is very versatile and flexible. At the sametime where it needs to shine assuming it doesnt want be left in the dust as CMS systems continue to blossom is workflow. Its imperative.

I can assure you when the versatile/easy to use/flexible w/ great workflow open source CMS hits and it will happen, dont know when but it will... Joomla will end up loosing both users, developers and ultimately its standing. Its simply a no brainer.

For any site of size in scale Joomla becomes problematic while people try finds hacks and solutions to what in reality are things that actually DEFINE CMS, Document/Workflow management. Instead one has to "trust" that a slew of people will get access to Joomla functions and hope/prey they dont make a mess of things.

Now why the Joomla core team would completely re-code Joomla from the ground up using modern three tier software architecture, provide such a nicer API interface to 1.5 and completely neglect ACL and workflow is just unbelievable. I mean what were they thinking? These are IMPERATIVES not "features".

User avatar
newart
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3177
Joined: Fri Sep 02, 2005 10:06 am
Location: Solar system - Earth - European Union

Re: Better ACL permissions – based on groups or users?

Post by newart » Sat Mar 15, 2008 4:06 pm

Quoting : Now why the Joomla core team would completely re-code Joomla from the ground up using modern three tier software architecture, provide such a nicer API interface to 1.5 and completely neglect ACL and workflow is just unbelievable. I mean what were they thinking? These are IMPERATIVES not "features".

I think it was too long to consider that feature... if you have to use a better ACL you have to re-factor (partially, I know it) joomla. Moreover I agree with you about what you have to consider imperative for a CMS, and a sort of lack is not only in the ACL area... :-[
former Q&T WorkGroup Joomla member - Italian Translation Team Member

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Tue Mar 18, 2008 2:11 am

I quote from the White Paper:
The Team should be a “group” of users which has although primary the permissions as group Registered, but Team should associate users that should SEE the same content items and USE components or modules that are invisible for unregistered users, users in Group Registered or in other Teams. Basically it is the horizontal extension of groups (roles) I’ve mentioned in the introduction.
I would simply define a Team as a group of users that have the same Publishing Permissions, and the same Viewing Permissions. From this follows that we need to have detailed control of both.

My previously mentioned Joomla! Hack gives Detailed Publishing Permissions to individual users (still no errors found). I have also created another simple Joomla! Hack (three lines of code inserted in a Joomla! module plus a new function added to the same module and also a new table) to give individual users Detailed Viewing Permissions. This is a very basic function, which makes it possible to define Menu Items as accessible for only certain users, and define other Menu Items as protected from all but certain users. Together, these two Permission Hacks give me complete control over my user permissions. A possibility is to go a bit further and hide any disallowed Menu Items from the individual user, but that is not consistent with how Joomla! works when we define (as an example) a section as accessible only to "special" or "registered" users.

Now. let us define a Team simply as a group of users. A Team table relating Users to Teams would be necessary to identify which Users belong to what Team. Then we can (with very little work) slightly modify the system described above to handle Teams instead of Users. Each Team Member would then be able to publish and/or edit (if he is given the "role" of Publisher or Editor in the normal way) ONLY within defined Categories, and each Team Member would be barred from using the Menu Items defined as Denied. And of course, a Team could also be given the privilege of accessing certain content hidden from all other Teams by defining certain Menu Items as Allowed for this team.

So in what way is phpGACL better? Anyway, I am pleased with the enhanced Joomla! functionality (for individual users, I have no need of groups yet) I have implemented, and the thing that really surprises me is how little work and little knowledge and Joomla! experience was necessary to achieve it.

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

Re: Better ACL permissions – based on groups or users?

Post by Hackwar » Tue Mar 18, 2008 9:18 am

compared to your solution, phpgacl is usable everywhere, also on access to components, access to certain actions, etc. and it adds an abstraction layer, which allows us to switch the whole system, not sticking with fixed queries, etc.
phpGACL is VERY powerfull.
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.

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Tue Mar 18, 2008 9:45 am

I apologize, Hackwar, for not being clear enough. Of course phpGACL is a very flexible and powerful system compared to my own small hacks, which is probably one of the reasons it is not fully implemented yet. I have browsed a lot of Joomla! code, so I have seen that some work on phpGACL is already done, and I suspect that as yet there is no consensus as to exactly how phpGACL should function in the J! environment. So we have to wait for some time until this is worked out. Also, the accompanying table structure is not simple and the table accesses could cause more overhead than is wished for.

No, my question should have been "in what way is phpGACL better FOR ME?" Will it give me better control of what permissions my users will have? Not really, not short term anyway, maybe when Joomla! is developed further in three-four year's time. The argument that I can not control components is duly noted, but practically speaking that is not important. Since all access to the components is made through the menus it is sufficient to control the menu items.

I realize I am not looking further than the end of my own nose, but when phpGACL finally is implemented it is not at all clear to me what I have to gain from using it. Possibly if Joomla! is vastly different from today?

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Better ACL permissions – based on groups or users?

Post by petoroth » Tue Mar 18, 2008 3:00 pm

the_real_svempa wrote: I would simply define a Team as a group of users that have the same Publishing Permissions, and the same Viewing Permissions.
I wouldn´t . I´ve written:
The Team should be a “group” of users which has although primary the permissions as group Registered, but Team should associate users that should SEE the same content items and USE components or modules that are invisible for unregistered users, users in Group Registered or in other Teams.

The little difference is:
The Team should consist of users that have the same Viewing and Using Permissions, however not from users that have the same Publishing Permissions. Then you have to make so many Teams you have users with different publishing-permissions.
I repeat again: The Team should be a group of users that should SEE the same content items and USE the same components or modules. Publishing-Permissions have to relate to individual users.
Why? E.g. you have 1000 Members divided into 100 Teams and only some of them will have Publishing-Permissions and most of them will have different Publishing-Permissions. You will not do Teams for individual users.
Evidently the Publishers inherit publishing-permission from the Team, what I´ve mentioned in my introduction in this forum topic.

User avatar
ukirfan
Joomla! Apprentice
Joomla! Apprentice
Posts: 19
Joined: Sat Oct 13, 2007 4:26 am
Contact:

Access control using pre-order tree traversal

Post by ukirfan » Tue Mar 18, 2008 7:44 pm

just like everybody else , i wish joomla heroes can add ACL feature in 1.6

"a picture is worth than a 1000 words"

...some of my thoughts & code help. i have gathered as powerpoint presentation .




Irfan
You do not have the required permissions to view the files attached to this post.

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

Access Management in Joomla! 1.6

Post by Hackwar » Wed Mar 19, 2008 1:25 pm

1. Introduction
1.1. Scope
This document should provide an overview about the new ACL system in Joomla! 1.6.
1.2. Objective of the document
This document is aimed at providing a basis for a discussion about an ACL administration UI.
1.3. General remarks
1.4. Definitions
1.5. License
GNU GPL
2. Description
The Access Control List feature has been an often requested function for a long time. First attempts at implementing a good solution have failed during Mambo times and left us with the #__core_acl_* tables. Since then we had a Google Summer of Code project on this issue, several core developers worked on this and at least two third party extensions have come up, providing a similar functionality. Although those third party extensions provided working code, this has always been more a quick&dirty hack than a real solution to the problem, since they were trying to fix something on a pretty high level of the framework, which is currently still broken at the basic level of the system. No solution, which has been declared stable, so far has really implemented a well working system, which fullfilled all the needs of the community and at the same time was easy to use.
When Andrew Eddie tried to implement an ACL solution in Mambo 4.5, he used phpGACL, which is a pretty sophisticated class. This class allows the maximum of flexibility, which is allready a bit to much in our case. However, the library is a good example for an ACL system and should also be the basis for the system in Joomla!
2.1. phpGACL
The following should explain the idea behind phpGACL and how to work with it.
2.1.1. Objects
In general, the system consists of three objects:
  • the user,
  • the action the user wants to execute and
  • the content object the action should be executed on. [optional]
To identify an object securely, each object has a parent category, called a section. For an action you can now for example specify a „manage“ action in the section „com_config“ and an action „manage“ in the section „com_media“.
Since we don't want to change a rule or create a new one for each new content item or user, there are also user- and content-groups. These can be stacked into indefinately deep trees.
2.1.2. Creating a rule
When we now want to create a rule, we connect at least one user with one action. As an optional parameter, we can add a content object to this, too, and use both user- and content-groups. Of course we can add as many of each of these objects to the rule as we want. When we check for the access right, each combination of user-action-content associated with that rule is coming back as good.
This is comparable with the structure of a sentence. We have a subject, a predicate and an object. The sentence is complete with a subject and a predicate, for example „John drinks“. This is very general, so we add an object. „John drinks wine“. This could be a rule, but its very static and only works for this wine. If we want to make it more general again, we could use something like „John drinks alcoholic beverages“, which would enclose wine, beer, schnaps, liquor, you name it. If you want to add another action, do it like this: „John drinks and eats wine and pizza“. Now, we know that you can only eat pizza and drink wine, but think about it that way as if you wouldn't know what all these words mean (like a computer). You could combine each of those and it would be a valid sentence. And thats basically how a rule in an ACL system works.
2.1.3. Critics on phpGACL
phpGACL has two major problems: Performance and the User-Interface. The class is currently not really performing good since every access check might require two additional database queries and checking the access rights to a series of objects prior to loading it from the database is also everything else than easy. There are also basic concepts missing to speed up the whole system and it mostly relies on caching on a file level.
The other problem, the User-Interface, is not really a problem of phpGACL. The problem more or less is the complexity of the system. Its just not possible to easily map a 3-dimensional system with two more helper constructs (the groups) onto a flat screen. This more or less annihilates the idea of a huge checkbox screen. The generic admin interface shipped with phpGACL is not really intuitive and will be to complex for the average Joomla! User.
2.1.4. Implementation in Joomla!
To simplify the system a bit, the rules should only refer to user groups and not to single users. This simplifies the system allready a lot.
2.2. Usermanagement
The new system creates another problem. Currently the user system is tightly coupled to the way Joomla handles users at the moment. In case we are using LDAP or another means of getting a user and its data, this will ultimately fail. For example the coupling of the author to the article through a JOIN in the SQL would break in case the article was created by a user authenticated through another user system. Also, com_users and com_user both rely on the #__users table being used instead of using a wrapper class. When re-vamping the ACL system, we will need to introduce another abstraction layer, that can be exchanged with other user systems.
3. Implementation in Joomla!
Although the implementation is basically build after the phpGACL class, the user should not be forced to use this system, but should also be able to use alternatives like LDAP or maybe a way better system than the core one. This means that we have to have a standardized API, which then gets adapted to the different systems internally.
This basically splits the implementation into 6 parts:
  • JACL class
  • ACL adapter plugin
  • Usergroupmanager
  • General Joomla! Access Manager
  • Component specific Access Manager
  • HTML snippets for content management
3.1. JACL class
This class is basically just a wrapper for the ACL functions of the underlying system.
3.1.1. Functions provided
The JACL class needs to provide functions to:
  • check for access rights
  • get all allowed content objects for a user and the selected action, optionally filtering by a content group
  • manage users and user groups
  • manage actions
  • manage content objects and groups
  • manage access rules
This is just a rough list of the functions needed. A more detailed list will have to be created when designing the system.
3.2. ACL adapter plugin
The different ACL systems should be added as plugins, which register on the „onAfterInitialize“ event, load the correct library and register the correct class in the JACL class. This allows to replace the system with very little effort by (in theory) just replacing the plugin. The choosen event is early enough in the process of Joomla! that this class should not have been needed yet.
If the plugins are interchanged, we have to make sure, that the new system can somehow take over all the objects from the old system. A conversion system will most likely have to be made by the developer of the alternative plugin. This could be supported by reading the XML files associated with each component.
3.3. Usergroupmanager
The usergroupmanager should be pretty straight forward. It needs to allow to add new groups and of course to edit and delete them and to assign a user to an unlimited number of usergroups.
The usergroupmanager of phpGACL is pretty much what we would need and could easily be integrated into com_users in the backend. For this please also refer to my other whitepaper about this.
3.4. General Joomla! Access Manager
This component is similar to com_config to set basic settings like access rights to components and the backend. It is driven by an XML scheme similar to the parameter system and should not need to support content objects. This means that we have a basic two dimensional system, allowing a grid of checkboxes to administrate it.
A good solution would most likely be, to save access rules per user group, although this means more rules in the system. It would allow to select a group at the beginning and then show a set of radio buttons or checkboxes to allow or disallow an action.
In the XML files behind the system, you can define which actions are to be used together with a content object, completely alone or both ways. This means you can set the general access rights to a component in this global access manager, where as you would do the content specific settings in the component itself. Maybe we will need two files to specify settings to be set in this global manager and those in the component itself.
3.5. Component specific Access Manager
Again similar to the parameter button in some components using com_config, this should be an iframe that pops up in the components context and lets you set the component specific access rights. I can currently not determine if content objects should be supported here. This is again driven by a XML file similar to the parameter system.
3.6. HTML snippets for content management
Although we have a „big“ access manager in the components as proposed in the previous paragraph, we still need a few code snippets to allow „regular“ users to modify the access system. As you can see in paragraph 5 we need a box to select the access item, to which we attach the current content item or we need a way to select an access group for a new content object. These snippets would be similar to the JHTMLList::accessLevel() function already included in Joomla and will most likely replace those.
4. phpGACL implementation
The class currently is pretty ineffective. With two more lines of code, I was able to cut the amount of queries by 40% at least. Although the idea behind the class is interesting, I think we should think about a complete rewrite.
For starters, each access call triggers one query for the groups the user is member of and one query to determine the real access right. With caching the usergroups on a pagecall basis, you can already cut the amount of queries in half.
The next option would be to load all necessary rights in the first call, instead of triggering a query for each call. In the end we have to check for a lot of things, like access to the backend in general, to the component in general, to edit at all and only then do we check if we have access to that specific content object.
All this is pretty ineffectively coded, which enforces my believe to rewrite this class, although the idea and structure behind the library is a good one and should definitely be used in Joomla!
5. Example-Implementation in com_content
com_content is a nice example on how the whole system could be implemented. Besides the basic stuff, like general ability to access the component, we need to get a number of content items, without actually being able to check the items before retrieving them from the database. In terms of performance, it is also extremely unwise to just get all items from the database and then check each and every single one of them, until we have arrived at our limit for the site to be rendered.
Basically, we should just use the same system as we do at this moment. Currently, we take a number from the #__groups table and attach it to the content item, be it an article, a section or a category. We do this in the same way, except that we now have a series of AXO objects with a „com_content“ section. This allows us to keep the interface basically the same and you still only select an entry from a list, instead of creating a big interface to select different access rights.
With selecting such an AXO object, you define an access profile and the beauty of it all is, that you now can extend this list of AXO objects as much as you want. But there is more. Instead of having a fixed set of rules for each of these objects, you can now define them as you see fit. You need one more group with differing access rights? Create a new content object in the ACL system and assign it the new rights and you are done.
This is also very nice for accessing the real data. Instead of taking each object, check our access rights on it and then discard or use it, we now only have to get all those objects the user is allowed to see or edit and in the query to the database we do a „WHERE access IN (<acl content object IDs>)“ This results in only very small changes to the system and should also not increase the load to much.
This is only an example implementation. If an extension needs more fine grained access rights and wants to do it in a different way, there should be nothing stopping the developer from doing it in a different way.
6. Installing extensions
When installing a new extension the installer needs to check if new access objects need to be inserted. These should be noted down in an XML file of the extension. We will need to create an XML scheme for this and decide if we want to use an extra XML file or the general component installation file. The installer should also have a function to reset the access rights by re-installing these access objects. If this function is not only in the installer, it could also be used to switch between two access systems, like phpGACL and LDAP.
7. Modules and Plugins
Modules and plugins should not need more access checks than „view“, which is why it should be enough to replace the normal access box in the plugin or module manager with a box that shows the usergroups, internally creating a rule „usergroup X and Y are able to view this module“.
8. Upgrade from Joomla! 1.5
The upgrade should be surprisingly simple. Since the default data would still be the same structure as in the current system, we wouldn't have to change anything in the content tables of the core components, which could just take over the new system. We would only have to go through all modules and plugins and create the apropriate rules for them in the system. This switchover should be without any problems.
9. Effects on...
9.1. Users
If the user has no need for the new system, he will not very likely come into great contact with it. Users in need of a more fine grained access control system will have to learn three new interfaces, although the way these work should be pretty straight forward.
9.2. 3P extensions
Third party extensions relying on the JHTMLList::accessLevel() function could run into trouble, depending on how we implement this feature. Older extensions, which read the #__groups table directly and don't use any of the ACL tables in Joomla should work fine, too. By keeping the old group scheme in the system as legacy, most of these extensions should work fine.
9.3. Performance
The effect on the performance can currently not be estimated. We will have to test this thoroughly before releasing it.
acl_overview.zip
You do not have the required permissions to view the files attached to this post.
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.

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

[33]Access Management in Joomla! 1.6: Usermanager

Post by Hackwar » Wed Mar 19, 2008 1:31 pm

1. Introduction
1.1. Scope
This document should describe a new Usermanager for the backend with the new functionality of the ACL feature.
1.2. Objective of the document
This document is aimed at providing a basis for a discussion about a new Usermanager with ACL features
1.3. General remarks
1.4. Definitions
1.5. License
GNU GPL
2. Usermanagerchanges in regards to the new ACL
This whitepaper should expand the explanation of the new ACL feature in regard to the user manager in the backend. The current user manager is very much fixed on the static group system of Joomla. The new user manager needs a lot more flexibility and should combine a few more functions. Specifically, the group management and user management need to be revamped.
3. Proposed changes
The goal should be to make the interface easier understandable for the user and to combine as much functionality in one screen as possible without making the interface to complicated.
The idea is to show users and groups in one screen in a tree structure, similar to the view in the windows explorer. Groups should be marked as such and be at the top of the list, where users would be below the groups. A user is always shown in all groups where he is member of. If he is removed from all groups, he is shown in the „Not assigned“ group at the bottom of the list. Assigning a user to a group is done through editing the user and selecting the different groups he should belong to.
From this screen you should also be able to change to the permissions screen, which would be specific to each user group. Since the access management should work similar to com_config with a simple button for extensions to get their custom access manager, it could be confusing to leave this in the users component.
Since some sites have a huge user base, the tree view of the users in the groups needs to be paginated, which should be possible through AJAX. A simple set of arrows to page up and down should be enough already, although for a fast forward the different page numbers could be shown next to the name of the group.
Additional informations about the group and the user, like the number of users in a group, the groups a user belongs to and maybe some basic access rights, could be shown through tooltips as it is currently done for articles in the frontend.
Since creating a group involves only a name and selecting a parent group, it would be interesting to do this through a modal window, which makes a slicker impression on the user than reloading the complete page for two form elements.
4. Effects on...
4.1. Users
The users will need to learn a new interface, but it seems to me as if this interface would not be more complicated compared to the current one and especially the ratio between gained functionality and a more complicated interface should be extremely good.
4.2. 3P extensions
There should be no effect on third party extensions through this change inside this component.
4.3. Performance
The performance loss through these changes should be neglectable.
acl_usermanager_0_1_hannes.zip
You do not have the required permissions to view the files attached to this post.
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.

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Access Management in Joomla! 1.6

Post by petoroth » Wed Mar 19, 2008 3:32 pm

For Hackwar
Ok. You explain the situation about the improvement very good. However you have mentioned only about the rule and permissions of access to SEE sth. or USE sth.
I have not seen anything about the rule of Publishers, Authors...

I agree, access rights to SEE or USE can go to USER-GROUPS.
But when You have to rule who, what were can add, manage, edit... it must go direct to the USERS.
I wrote detailed about it my topic: http://forum.joomla.org/viewtopic.php?f=500&t=272650

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

Re: Access Management in Joomla! 1.6

Post by Hackwar » Wed Mar 19, 2008 3:47 pm

Whats the difference between seeing something, touching it, changing it, deleting it? These are all actions. If you really want to set all these for each user individually, you would simply go insane. In my current project, I have 3-4 different groups of people, with 50 people that will be in these different groups. If I had to set these access rights for each of these users seperately, for 50 people... Its just impractical. The better solution would be to create a new group if you need another set of access rights. Publishers and Authors are nothing else but groups which have some rules like "can edit" and "can publish" attached to them.
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.

petoroth
Joomla! Apprentice
Joomla! Apprentice
Posts: 36
Joined: Mon May 07, 2007 8:53 am
Location: Slovakia, Europe

Re: Access Management in Joomla! 1.6

Post by petoroth » Wed Mar 19, 2008 6:13 pm

Hackwar wrote:Whats the difference between seeing something, touching it, changing it, deleting it? These are all actions. If you really want to set all these for each user individually, you would simply go insane.
I think no, I wouldn´t do insane. Probably you didn´t understand what I wanted to explain and you didn´t read my topic carrefuly.
In my topic I wrote:
2. Example – Very large web site
In a very large web site is very common to divide responsibility for the web content. E.g. first author (editor or publisher) is responsible for the section Sport, another for Culture... It means that the first author can manage items only in his section Sport and doesn’t have the access to manage items in other sections.

When I create a group for users who should be Authors, how can I set individual permissions for each author in my basic example. Then I have to make so many Groups I have Authors. Publishing-Permissions have to relate to individual users.
E.g. I have 1000 Members divided into 100 Teams and only some of them (10) will have Publishing-Permissions and all of them will have different Publishing-Permissions. I will not make Groups for individual users.

User avatar
the_real_svempa
Joomla! Intern
Joomla! Intern
Posts: 55
Joined: Wed Oct 24, 2007 11:23 am
Location: Sweden

Re: Better ACL permissions – based on groups or users?

Post by the_real_svempa » Wed Mar 19, 2008 7:42 pm

OK, that really simplifies things, from my point of view. I was aware that not all team members would have publishing permissions, but I thought you meant that all who had would have the same publishing rights and only were able to publish within their own Team. You wrote:
It is very necessary to control Who? What? Where + How? and For whom? (these interrogatives I will explain later) can PUBLISH items, although only for his group.
The difference between you and me seems to be that I want a working system right NOW, while you are satisfied to be able to influence future development (which I also find very commendable). This means that I am looking for simple solutions that have 95% functionality rather than a full-fledged Access Control Lists system that covers precisely everything.

I am trying to implement a "good-enough" (not "perfect") Permission Control System with very small changes to the present code, which means that the previously existing basic functionality will need to remain. An example of this is the concept of hierachical "groups" (I quite agree that these are NOT groups but 'roles') with vertically increasing authority. Controlling publishing permissions for a certain user, to give an example, presupposes that the user already has been given the 'role' of Publisher.

So far I have been successful in creating a well working Joomla! Hack for individual publishing permissions, and another for individual menu item access permissions (please note that this hack cannot be used if SEF is enabled, since it works off Menu Items ID:s). So what would more be needed to give you at least 95% of what you want?

OK, let me try to describe what would have to be done - not much actually! We must first have a new table to describe the Teams, in this table each Team is identified by a unique ID and each row would contain columns to hold a description of the Team, who is the Team Leader and perhaps several other things. Then we must have another table to define what users belong to what Teams, this can be done with just two columns by relating User ID:s to Team ID:s. Finally we change my existing hack for individual menu item access permissions to Team menu item access permissions, which can be done with just a little more work.

So what is left? Module permissions, of course! Each Team wants to be able to view its private modules using some kind of module viewing permissions system. Again we need to consider how Joomla! works today, we already have a kind of module viewing permissions system! For example, sometimes we need to collapse the right column to make place for an image gallery, a forum or something else. This normally means that several Modules are not to be published for certain menu choices. Also we can have unpublished Modules that are not to be published, and we can also define certain Modules to be published only for certain user 'roles' (registered, special) .

All this functionality needs to remain, so when a web page is generated all these checks must be made for each module. Now we want to add Team permissions to the present system, this means to me that we FIRST consider if the existing rules allow us to publish the Module, and if so - we THEN check to see if our new Team permissions make it necessary to deny the request.

A simple example: Let us suppose we have three different teams T1, T2 and T3. The only difference between them (for the sake of discussion) is that each Team has it's own Team Menu, which of course is a module, in the right column. Each time a web page is generated for a user who is a member of at least one of these Teams the present rules are applied first. If the Module is not connected to a certain menu item according to present rules, the Module will not be shown whatever Team permissions we have defined for this Module.

Let us next suppose that present rules allow publishing of all three Team menus on the current web page, with no Team permissions the user would then see all of them. Applying Team permissions the user would see only the menu(s) for the group(s) of which he/she is a member. A Team permission system would consequently have to define WHAT modules are to be controlled by the system, and WHICH users are to be able to view them.

Is this difficult? Not at all! We simply define another small table to relate Team ID:s to Module ID:s. We also define a rule, saying that if a Module ID is in this table, the Module is controlled by our Team permissions. Joomla! has today a PHP function in helper.php (in libraries/joomla/application/module/) that decides what Modules are to be published using a database query:

Code: Select all

$query = 'SELECT id, title, module, position, content, showtitle, control, params'
			. ' FROM #__modules AS m'
			. ' LEFT JOIN #__modules_menu AS mm ON mm.moduleid = m.id'
			. ' WHERE m.published = 1'
			. ' AND m.access <= '. (int)$aid
			. ' AND m.client_id = '. (int)$mainframe->getClientId()
			. $wheremenu
			. ' ORDER BY position, ordering'; 
In this query we add one more AND like this ($user_id holds the current user's ID):

Code: Select all

AND $user_id in (SELECT user_id FROM #__team_users tu, #__team_modules tm WHERE tu.module_id = tm_module_id AND tm_module_id = m.id)
The SELECT will give us a list of all user ID:s that are members of any Team that has permissions to view the Module that is under consideration for publishing, identified by it's Module ID m.id.

That is really the only code change necessary (perhaps a line or two more to take care of the situation when the user is a guest), the rest of the job is done by the relational tables we created. Not tested of course, and there might be some formal error in my syntax but the logic should be correct. Some small program to maintain the tables would also be necessary, no big deal, I have already created a small suite of such maintenance programs for my existing Joomla! Hacks and these would be very similar.
Last edited by the_real_svempa on Thu Mar 20, 2008 8:51 am, edited 3 times in total.


Locked

Return to “Accepted - Archived”