[15]Access Management in Joomla! 1.6

[the_real_svempa]

One problem when making ACL hacks is exactly WHERE to put the hacks. In the absence of triggers one cannot use plugins, the only thing possible is then to modify one or several core modules. But which one, and exactly where? Some places are better than others...

As an example, by moving my hack (plus a small change in the code) for menu item access to another place in the same module (a few lines after the start of function createURI) it was possible to achieve the following:

1) The hack now works whether SEF is enabled or not.

2) No UNAUTHORIZED error is thrown, instead the denied URL is redefined to whatever is best for a particular site. As an example, if there are paying and nonpaying registered users an attempt by a nonpaying user to access a menu item leading to a page reserved for paying members can be redirected to a recruiting page.

3) It is possible to see the redefined URL by doing a mouseover of the menu item.

I have also changed my two first hacks (suggested by signature biowan) so they only affect frontend users (registered, authors, editors, publishers and guests).

It would be interesting to know whether anyone has tried to make a description of how Joomla! works internally. A big advantage is the building-block approach, this is selfexplaining to a large degree. But what goes on in the core modules is more difficult to understand. Perhaps it is seen as a good thing since it makes writing hacks more difficult. On the other hand, the hacks of today might be the Joomla! code of tomorrow?

[the_real_svempa]

It is often said that "the devil is in the details". This goes also for the Joomla! ACL.

When protecting content from selected users, be they guests or registered, we have (at least) two choices.

One is to throw an error when a user tries to access whatever content is denied to him/her. Another is to modify the menu so a user will not even SEE any menu choices leading to denied content. And of course - if the user manages to reconstruct the URL - to throw an error anyway.

For my own sites I am using the "swMenuFree" system, and I have found it easy to modify this module so any denied menu items simply are not shown. While the standard Joomla! menu system is much harder to hack...

[masterchief]

Tracker Task:
http://joomlacode.org/gf/project/joomla ... m_id=10744

[the_real_svempa]

It would certainly be very interesting to find out what is behind that link to a Tracker Task. But I get a "Permission denied" trying to find out.

Another interesting ACL detail: The gallery Phoca Gallery now has a quite good permissions system implemented. This has made it possible to give detailed viewing rights to individual galleries and the system works very well together with my own Hacks. My family page http://www.bankel.se is much improved thanks to this!

[masterchief]

the_real_svempa, I'll look into it. But the only thing in the task is a cross-link back to this forum What out for detailed discussions on the Dev mailing list.

[dioscouri]

This is a long thread to just now discover (and a lot of info to digest), but have any of you used JUGA for managing user group access? I ask because it seems to address many of the issues on the table without hacking core Joomla files...

http://extensions.joomla.org/component/ ... Itemid,35/

[the_real_svempa]

JUGA seems to be a great group ACL system, and taking a new look at it I can see it has been vastly improved in the last months. Also, it is no hack and can be installed like any other extension. It is not free, but not really expensive, and you can evidently get good support. For somebody who runs a big site JUGA could solve many problems.

However, my own main problem was controlling publishing permissioons, and JUGA does not address that at all. Also, group access is not really my problem either since my sites have a small number of users. I prefer giving specific viewing and publishing permissions to individual users, even though I have implemented a Team functionality.

Like JUGA my own changes make it possible to hide menu items from users with no access rights. But this is accomplished through the use of a modified version of the swMenuFree extension, I found it too difficult to make the necessary changes in the original Main Menu module. So this is really no Joomla! hack :-)! And I like the visual flexibility that comes with the advanced menu configuration tool that swMwnuFree has.

[dioscouri]

@the_real_svempa

Sorry to not have responded sooner!

I prefer giving specific viewing and publishing permissions to individual users, even though I have implemented a Team functionality.

With JUGA, you can create an infinite number of groups and assign rights to each of those groups, all the way down to which section or category they can publish content into. For customized rights for individual users, you would create a unique JUGA group for each user...

JUGA operates off of the variables in the page's URL. You tell JUGA which variables a component has (in the case of fireboard, for example, you would tell JUGA: "func", "catid", "task", "id", etc). Then you tell JUGA which groups have access to which combinations of those variables.

And like I said before, you can have a group that's only got one member, so you have individual access rights.

Let me know if you'd like to try it out.

Thanks!

EDIT: I had also meant to ask: how would it be possible for us to get involved with the ACL workgroup (if there is such a thing)? We're three guys over at Dioscouri (though we're hiring a few more this summer) and we'd like to offer our services to the Joomla! Core team (for free, of course).

[Scrat4immer]

Hello,
JUGA is a great tool for somebody who has tons of time and is probably doing this professionally. But I think there are a lot of non-commercial and "amateur" users (if not more than professional users) who only use joomla for very small projects like a picture website or a bloglike website. For them a JUGA like ACL, where they have to add the variables of every site is way to complicated and time consuming. Also I think that working with the variables is more like a workaround that was developed due to the urgent need for an ACL solution, than a real professional constant solution to the ACL problem. I'm not saying that JUGA in general is a bad component, its just not very handy for someone who is working on a small non commercial website. For everybody else who actually is working on a professional website, JUGA offers one of the most customizable ACLs.

However...

I have been looking at other open source CMS lately and almost all of them have a more flexible and customizable ACL than Joomla. I'm glad to see that this topic has been accepted by the Joomla core team.

Most of the other CMS use a simple grouping system where users can be assigned to multiple user groups. This is a simple and easy to understand ACL. A 3rd dimension however could bring the advance to the other CMS. Like creating groups and then also having something like group categories where groups can be "grouped" together and been given some "default" access rights that are valid for all the groups that are in this group category. Thats what I think would be all we need for ACL.

Scrat4immer

[newart]

Most of the other CMS use a simple grouping system where users can be assigned to multiple user groups. This is a simple and easy to understand ACL. A 3rd dimension however could bring the advance to the other CMS. Like creating groups and then also having something like group categories where groups can be "grouped" together and been given some "default" access rights that are valid for all the groups that are in this group category. Thats what I think would be all we need for ACL.

agreeing

[p.pCoder]

With JUGA, you can create an infinite number of groups and assign rights to each of those groups, all the way down to which section or category they can publish content into. For customized rights for individual users, you would create a unique JUGA group for each user...

JUGA operates off of the variables in the page's URL. You tell JUGA which variables a component has (in the case of fireboard, for example, you would tell JUGA: "func", "catid", "task", "id", etc). Then you tell JUGA which groups have access to which combinations of those variables.

It is not at all clear that JUGA can do what you say it can.

Based on posts in your own forum, it seems like JUGA cannot live up to these promises in J 1.5.x

• http://www.dioscouri.com/juga/howto/res ... shing.html
  http://www.dioscouri.com/forum/func,vie ... 5/catid,6/

I'd like to be sure that JUGA really does provide real ACL functionality before I spend the money and invest my time into it.

[ircmaxell]

Like creating groups and then also having something like group categories where groups can be "grouped" together and been given some "default" access rights that are valid for all the groups that are in this group category. Thats what I think would be all we need for ACL.

That's something I would stay away from... "Group Categories" just opens another issue... It's just like the section/category hiearchy that we have now... I, personally, would view groups as more of a container. All groups can contain either users or groups... That way, you can create a hiearcy... And are not bound by the 2 layer system...

[Scrat4immer]

Yea thats also what I meant. Sorry for the confusion. But yea... I personally like the "ACL" of Docman. Its really simple and pretty much what we need, except that you can't put groups into groups but I think it should be possible to make an ACL for Joomla that can do that.

[Kayz]

I second petoroth's post on page 2, here is my thread:

http://forum.joomla.org/viewtopic.php?f=431&t=306275

Usergroup levels are and should be made mandatory and implemented.

Its a major suggestion, this feature should come to anybodys mind by default without having to think. Something like Joomla should have this by default and should be mandatory. When i installed Joomla i thought this particular feature would be available by default but to my suprise it wasnt.

The administrator should be able to assign different user groups with different user level access capabilities. So if i assign x user to x group then they should only be able to edit the section they are allocated to and not others. Also there should be features such as delete and an edit time so a rougue user dosent go round editing and destroying everything.

I was going to assign some roles to a few people on our CMS website but i was afraid that if they ruin some areas if things dont turn out so daisey in the future? A forum called vBulletin has different usergroup levels as to what the users can and cant do which is awesome and gives the administrators plenty of control.

I would strongly strongly suggest Joomla implements a user managment features where different users are allocated to different areas to keep up to date and is only able to add/edit the sections they are responsible for and not others.

I sincerely hope this is taken on board by the Joomla Dev team, as i dont think it should be the way forward with modules/plugins.

[tensoja]

I sincerely hope this is taken on board by the Joomla Dev team, as i dont think it should be the way forward with modules/plugins.

[2]

[metux]

Hi folks,

I'm currently working on that issue: implementing an group-based access control API.

http://j.metux.de/index.php?option=com_ ... view&id=59

[esambe]

In my opinion we need to control access in 2 different ways:

1. A role based access control (this is what we have in current Joomla implementation): each user has a certain level of technical experience/education and this determines to what degree he/she should be able to use advanced features of your system, i.e. use the editor, upload images, manage items.

2. A group based acces control: the ability to organize users in groups (a user can participate in more groups) and make groups responsible for certain areas of the site. I think particularly the group based access control should be related to categories rather than components. My suggestion would be to use both the group and the role at this level.

I think this is a start in the right direction,
1. Let there be identified all pieces of code that consult the traditional joomla core security system as it is in 1.5 (that should be easy)

2. Let all the functions for which permission is sought in these instances be listed, sorted and grouped. A brainstorming session can yield a more logical and comprehensive list of funtions. This will be topped up by the (development of the) ability to DEFINE new functions that had not been previously thought about, and whenever the need arises.

3. Let the traditional roles be converted to/replaced by groups that have predefined rights based on the lists above, with the use of more than one group if nescessary (e.g The Joomla Author as we know it, may have to draw permissions from more than one sub-group to achieve what it does in say 1.5.5 or may be defined from scratch by assigning the exact list of functions that it needs to do what it has always been doing,
another example, the publisher group will inherit from the author group and add the publishing function onto itself as well)

4. Create an interface that allows the creation of custom groups by (component) developers where they inspect what (standard) groups already exist and what functions they are allowed to carry out and then decide whether they want to inherit from those groups or define a custom list of functions for their new group. set limits to avoid chaos.

5. [This point should be implemented before point #4 of course] Create an engine that will allow consultation of the security engine whenever the joomla core comes across ANY code that is requesting for or checking for certain types of authorisation by invoking ANY group name as one of the parameters of the invokation.

This approach will allow two things
-->backward compatibility- non-techies need not learn new stuff, they just need to look out for the traditional group names they are used to and use them
-->component developers are now free to produce a new breed of components that have the flexibility of acl

im not a joomla expert but call me in for any acl brainstorming session and ill be able to contribute coz severally ive wished i could just define my own group instead of being limited to the joomla groups,
currently i have had to go out of my way to write code that is oppressed by the current 'regime' of inflexible joomla roles, so..

i vote for a beta version of acl in the joomla 1.5 series
im ready to help out on this beta testing, ideas, bluh bluh, holla at www.ensinke.com
cheers

[indra2004_id]

I am wondering if this white paper has been implemented.
If J1.5 really has the improved ACL, I can say that it is a giant step forward.

[newart]

sorry but I don't understand your wondering as we are in the accepted white paper area

[indra2004_id]

CMMIW, but I want to know if the ACL as suggested in this white paper has been implemented in the current version of J1.5

[Hackwar]

No, since the whitepapers are for 1.6, as can be seen in the title and from the fact that 1.5 was released before the whitepaper process was even started.

[indra2004_id]

Oh, I see
Well. thanks for the explanation.
I think that this white paper is very good and address an important point, where Joomla has been lacked since 1.0
Some people try to make an extension, but almost all of them are just hack, which must be upgraded whenever Joomla is upgraded.

[newart]

...on my own I'd like to know the work in progess scale... just for curiosity, but apart from the white paper document where can we see how much % work is done?

[Malenx]

Per masterchief's earlier post... http://joomlacode.org/gf/project/joomla ... m_id=10744

[newart]

thank you! seen the link but all seems not started...

[indra2004_id]

Yes, seems like it's still long way to go for the people (including myself ) who are dreaming about the feature readily embedded into standard Joomla installation.

[chas]

Anyone checked how the forums use "user permissions"??

hello i am used to invision usergroups for intuitive administration

the present ACL is way too generalised

IPS uses "if" clauses in their scripts to control access to certain functions; dont know how or if they would slow joomla's design.

But each user feature is an ON/OFF switch eg, avatar, can use html/bbcode, can upload, can publish, can edit etc

Each category/forum/subforum (joomla equivalent = section/category) checks for the groups it s allowed to show to.

SO there are 2 major points of restrictions:

1. the usergroup restriction and

2. the area/content-specific restriction:


can this be done thru extensions or core?


BTW, am i the only one that sees ROLE and GROUP as essentially THE SAME??

hansma2go wrote:In my opinion we need to control access in 2 different ways:

1. A role based access control (this is what we have in current Joomla implementation): each user has a certain level of technical experience/education and this determines to what degree he/she should be able to use advanced features of your system, i.e. use the editor, upload images, manage items.

2. A group based acces control: the ability to organize users in groups (a user can participate in more groups) and make groups responsible for certain areas of the site. I think particularly the group based access control should be related to categories rather than components. My suggestion would be to use both the group and the role at this level.

[ircmaxell]

BTW, am i the only one that sees ROLE and GROUP as essential THE SAME??

Yes.

Basically, the difference comes in inheritance...

Role based has no inheritance. You get the permissions of your role, and that's it. If you want to add permissions for a single person, you need to create a new role.

Group based has multiple inheritance. You get the permissions of any group you belong to (in a heiarchy). So, to add permissions to a single person, create a new "group" with those permissions, and add the user to that group.

For small sites, they are practically the same. But as the site grows (in terms of users), group based is easier to maintain. That's how most forums operate...

[chas]

the reason i mentioned it is that you are complicating the concept by introducing 2 terms that mean the SAME THING. ( and doubling the coding ?)

If you mean ROLES as joomla's default usergroups (inheritable in forums such as IPB)
eg ADMIN will ALWAYS have admins, Moderators WILL always have moderators and USERS will have registered user, GUESTS as anon


and the CUSTOM GROUPS

then you can have a functions to clone groups based on the ROLES

[esatterwhite]

I don't know if it was brought up in this thread, but I think having a slightly more granular control over what users can edit/publish would be a very nice feature.

For example, I may have a large group of editors, but I don't necessarily want them all to be able to edit everything on a given sight. instead, the author of a given content item should be able to specify who is able to edit their article by means of perhaps a drop down list of current users on the sight. Admins and super admins would obviously retain the ability of complete control.

So the author of an article could populate a list of people who would then have the rights to modify / contribute to their article OR select 'All' to allow the entire user group -editor and above to edit/ contribute to their article or only list themselves.

This would also give the super administrator the ability to restrict people from being able to edit certain items on the site. And it would also be an easy way for people on a community type of a site to create their own quasi-groups to collaborate on content

I think the general consensus of the thread is that joomla, as it stands now needs a bit more control, It is too heave on the 'All - or-nothing" approach.
Or at the very least a simple editable/not editable option would be nice.