Joomla! Discussion Forums

I was reading the roadmap about the ACL enhancements and I was wondering what the 'vision' was in more detail.  It seems like a 30,000 foot view of what it is going to be.

I was wondering if the ACL was going to effect the access of components?  Are we going to be able to say specifically what users and or user groups have access to certain components in both the back-end and front-end?  How about specific content on a page when content is created?  Say we want everyone to be able to read an article except the last paragraph and we want only register users or certain users and or user groups to view that last paragraph on a page will that be possible?  Or should I say part of the vision?

Just curious mainly   Thanks for any info!

That's stage one.  Stage one is about configuring "things you can do".  This is actually the easy bit because generally you are asking a yes/no question.

That's stage two.  This stage is all about "what content can I see or hide".  This is a lot harder.  Our current system is very simple and extremely efficient in terms of code, but is not overly flexible.  But with flexibility comes a cost - performance and usability.  We need to make some trade-offs to give you both

Hrm, that would not be easy but I would imagine you could craft a mambot to emmulate that.

Hope this helps.

Actually, it looks like someone (marlar) has already created such a mambot - mosIF:
http://forum.opensourcematters.org/inde ... l#msg19218

First, thank you masterchief for your reply!  This is exactly what I was looking for.

Now this is very cool and exactly what I am looking for!  I'm actually downloading a copy of Drupal just to take a look at it and see how it handles things.  I'm going to be using Joomla for sure but want to educate myself with Drupal since it seems to be a pretty stern competitor of Joomla.

[quote=∓quot;masterchief"\]That's stage two.  This stage is all about "what content can I see or hide".  This is a lot harder.  Our current system is very simple and extremely efficient in terms of code, but is not overly flexible.  But with flexibility comes a cost - performance and usability.  We need to make some trade-offs to give you both [/quote]
That's a perfectly acceptible trade off IMO as I'm sure others will agree.  IMO this is too important not to have.

Ah yes!  I remember reading about mosIF.  There's just so much to keep track of it's easy to forget things. 

Having read now through most of phpGACL Manual (a recommended reading before posting to this thread! 8)), I've to say that you made a very good choice for the Joomla ACLs.

Unfortunately, up to 4.5.2, only ARO groups have been defined in the database (with an easily removable restriction of only one group assigned to each user), with "hardcoded mini-ACOs" outside of phpGACL.

This wrong definition of ACL in 4.5.2 should really be treated as a major bug ;) and improved asap (Joomla! 1.0 ?) to avoid further wrong implementations in 3PD components...especially that it's minimal fix is just a couple of SQL requests to the database...

A few very Simplified ACL (Access Control Lists) definition for lambda readers (adapted from the ACL manual, and not replacing its reading):

Until now most core function and 3PD components check access of the user's ARO group against a defined ARO group level (and sometimes even more wrongly just compare to the ARO group id...), as defined by 4.5.2 (e.g. "Registered, or Author"), and not the ARO itself (user) against a properly defined (by the site admin, default by Joomla or component) ACO and AXO, letting phpGACL find and choose the corresponding ARO group.

It would be damn good to at least define properly a basic set of ACO and simple basic 1-to-1 rules for the existing ARO groups:

existing ARO groups (pro-memo):

Public Frontend
  Registered
     Author
        Editor
            Publisher
Public Backend
   Manager
       Administrator
            Super Administrator

Corresponding ACL ACO (Access Control Objects) would be:

Read-Access to public frontend (for Public)
  Read-Access to frontend members-only items (for basic Registered users, not including public items)
     Edit-Access to frontend (for overall Authors)
        Reviewer-Access to frontend (for overall Editors)
           Final-Approver-Access to frontend (for overall Publisher)
Public Access of Backend (right now means full access of fronted LOL) -> rename to "Full-Frontend access"?
   Read-Access to backend for Managers
       Edit-Access to backend for global Administrators only
            Access for global Super Administrators only

And maybe one AXO, like: "global site", setting the layers structure...

Then define default access rules like:
Root
|– Public Frontend ( ALLOW [ Read-Access to public frontend ] )
    |–   Registered ( ALLOW [ Read-Access to frontend members-only items ] )
    |     |– Author ( ALLOW [ Edit-Access to frontend ] )
    |     |– Editor ( ALLOW [ Reviewer-Access to frontend], ALLOW [ Edit-Access to frontend ] )
    |         |– Publisher ( ALLOW [ Final-Approver-Access to frontend ] )
    |– Public Access of Backend ( )
        |– Manager ( ALLOW [Read-Access to backend for Managers] )
            |– Administrator ( ALLOW [Edit-Access to backend for global Administrators only] )
                |– Super Administrator ( ALLOW [Access for global Super Administrators only] )

Then, it would really be great to load automatically the ARO id (not the ARO gid) of the logged-in user into the $my global variable to allow components to directly and easily call the phpGACL acl_check() method.

Make a new multi-select-item in mosHTML class (welcome to take the one of CB) and implement a backend ACO and ARO selection item for each component/module, allowing the components/modules to fine-grain their accesses later.

Finally make available as part of mambo.php/joomla.php and document the standard ACL calls.

It's crucial that core/components/modules don't refer to hard-coded ARO groups or admin-set ARO-groups, but to admin (backend) selected ACO&AXO, with proper Joomla-system-default values.

The very minimum would be to define those ACO, AXO and rules, and populate the database with the default values using simple requests (and maybe update the phpGACL library to the latest release).

I would really welcome a phase 0 for ACL, where the ACLs are properly defined, and editable in the backend, so that core-team and 3PD can start implement proper ACL checks.

The above is just a proposal and start of an ACL design proposal for Joomla!, going a little further than the usual "We need ACL" statement. Hope I didn't duplicate someone else's work...

Your feed-backs (after the recommended reading ) and design proposal enhancements/rework are welcome. If this is agreable by the core team, we could then contribute with a submission of a small set of SQL requests and code improvements .

Thanks Beat.  I realise I made a mistake with the partial implementation in 4.5.0 and I should have put just a little bit more work into it then.  But then again I've also learned a few things or two since then as well.

I do not want any schema changes for Joomla! 1.0 so ACL changes are not possible.  However, I should be able to bump the stage 1 implementation into Joomla! 1.1.  In addition, we can also set up an Auth & ACL workgroup to look at the best modelling of the ACL's.

Hi Andrew,

No worries, we all learn quickly a lot with Joomla! Fully understand your stability- and deadline-conscious decision. I didn't know myself about phpGACL until recently , when I had to correct a fine-grained permission problem in the CB moderator module .

ACL Phase 1 in 1.1 would already be very good news. Better a good true ACL implementation and phase 1 in 1.1 than a bad one in 1.0

Email/Post me if I can help something . Other persons wanting to contribute to the Joomla! ACL design can already start now by commenting/feedbacking my proposal/or proposing something else on this thread without urgency to form a special access/authorization/security group. But I know the recommended reading takes some time before others can feed-back here

I'm agree with Beat.

let us know how we can help you guys to have a good basic implementation on 1.1 soon.

Hi folks,
after reading the thread, I thought about writing a mambot or something like this to include the phpGACL library, but when I looked in the help-section there was a description that this library is allready implemented. Am I to late? Or is this only an outline and the real work still has to be done? In this case I would start right away...
In hope of clearification
Hackwar

As far as I know, there are a lot of real work yet to be done... if you see the roadmap the true aplication is on the v1.3 more or least.

Yeah, I saw that, but nevertheless someone could already have made the work.

My idea was to write a mambot, which practically only implements the phpGACL in Joomla. Everyone that wants to use the ACL can do so, all the others use the old system till everything is ported to phpGACL. The mambot would just be a Joomla-installable package of the library. That way you could work it like patTemplate. Thats my idea so far. Is my approach correct? (I'm kind of a newbie...)
Hackwar

phpGACL is already included in Joomla!

it's in includes/gacl.class.php and includes/gacl_api.class.php

It's not really the latest version of it, but it's there and (partially ) used.

The problem is not including phpGACL but:
step 1: configuring the default settings it the right way (not only groups, but all the rest)
step 2: allowing the admin to define all ACL objects and access rights
step 3: starting to use it as today, but the right way in the core and in 3PD components (today not possible, because of partial definitions)
step 4: using it more broadly and in more details than today.
and maybe update phpGACL to the latest version

As I understood Andrew, step 1 and maybe step 2 could occur in Joomla 1.1 already , which is great news, as it would give a solid ACL foundation, allowing the core team to start using it the right way, as well as all of Joomla! 3PD. But for full effect you will have to wait 1.2 or 1.3 probably.

A mambot alone will very probably not solve your problem, sorry.

As far as I can see, it is just a dummy at the moment. The data is a static array and most of the functions are empty or just commented areas...


Why not just take the standard values? Mambo must have worked with some values up till now.


It probably makes the whole stuff more complicated, but you could put a special configure-page in the admin-panel. In the case of a new user, he gets the standard-values and if the admin feels more advanced he/she can use the configurepanel and change those accordingly. I think its very important to have the library included, even if it can only use some "static" data and no new ACOs can be added. When the library is included, the changeover to complete support will be more smooth and when its done, you can simply activate the admin-acl-panel. Thats my idea.... I hope I can give you some code soon which could be implemented.

Hackwar if I can help you with something just let me know.

Does anyone have a copy of the PHPGacl manual?  I would love to read this, but the link to the manual is either borked or inaccessible.

The complete (and as far as I think very good) manual is included in the downloadable package of phpGACL and I have no problems accessing http://phpgacl.sourceforge.net/ Probably just have to try it again....

You're right there's no problem getting to the site.  It's the manual link that doesn't work, but since it's in the download, I got it that way.  I agree, excellent manual, reading it now.  Thanks for clarifying.

Hi folks,
at the moment  I have a problem. I am almost done with the "implementation" of the gacl.class.php, but I'm stuck with the SQl-table-structure. ADODB has this XML-scheme and I'm not quite sure if I read it correctly. For some reason the setup.php does not work on my testserver either and I would be more than greatful if somebody could translate the XML-DB-structure into a SQL-DB-structure for me... 
Hackwar

Got a bit done, but sorry, I'm just a newbie. So I hope someone can do the rest? I came till line 266, downloadable under

//EDIT: took the link out, because its outdated

I think I have a to learn a lot more....

ACL is one of those feature that is a year late and that (based on the roadmap) will not be implemented until the end of next year. I don't understand why it gets such a low priority. Yes the usability of Mambo is important, but everybody is suffering from the lack of proper ACL. 3DP devs have to hack their own system and you end up with multiple ways of doing things on one site.

What would be needed to complete the ACL jump for Joomla 1.1? It seems to me that Masterchief was close to have a new user management system working in 4.5.3. Alex Kempkens knows very well how gACL works and was willing to build a system for us on 4.5.x in one week.
Now we have Beat that apparently knows where most of the fixes should happen.

What's preventing this from landing in the coming month?

I think the first step would be to implement everything correctly. Just like patTemplates, gives us the engine and let people and 3DP developers use it. We can always implement the full user management as a component, but at least 3DP can take advantage of the new feature.

Hi folks,
its me again. I've looked now over the complete gacl.class.php and think I've got it right now. You can download it at the end of the post. I would be glad, if somebody could correct my work. I've made a dump from the database, too, that it can be implemented in the install-procedures. I'm now going to look over the gacl-api and admin-interface to include it into the whole stuff and I will try to come up with some usefull generic entrys for the database.
You'll (hopefully) here from me soon

//EDIT: Took out the url/file cause its outdated

Thanks for the quick-start.

Sounds interesting (Looked at it very quickly, diffed it towards 3.3.5). Looks like you also updated to the latest 03 September 2005 version 3.3.5 of phpGACL :)  ?

Are we missing the corresponding gacl_api.class.php file ?

We also need to think about a simple yet powerful backend admin interface to define the ACLs correctly (see my previous posts). The phpGACL admin interface is ok for advanced users, but I would prefer to see a simpler interface (like the permissions-matrix of our sourceforge).

Two feedbacks:

- this change seems strange and maybe reviewed:




- One idea, lowering drastically the diffs towards the original phpGACL (simplifies updating versions) and reducing errors-possibilities: you could just rewrite/inherit of the method: $this->_db_table_prefix  and let it return "#__" or "#__acl_" , so the changes are much less.

I used the most recent version available at sourceforge. I don't have the api.class done yet, its in progress. I hope to have this done in 2 or 3 days.

To the backend interface: I'm currently thinking about it and have a few ideas allready.
The layout will consist of tabs for the ACLs, ACL-groups, user-groups and item-groups. In each tab is a list of the corresponding items and in the toolbar you will have the options to delete, edit and create them. When you create a user or a content-item (menu, article, ...) you will have to choose in which group you want to put them. In case of content it makes it all a bit more complex, because you not just have to put content in a section/categories, but also in an access-group. At the moment this seems to be the least complicated to code for me.



To 1: As I looked over the code it was difficult to read this, in that I concur with you, but the original author made it that way because you have a LOT of joins in the SQL statements and that way you don't have to write so much. I don't really know how to do this right, probably someone more experienced than me can improve that later. (at the moment I just want to get an ACL thats somewhere to the way of being good)

To 2: phpGACL uses the ADODB abstraction layer and there for the changes are allready very big. As far as I know, ADODB will be included into Joomla later, but as long as it is not, I want to keep the overhead as small as possible. The command that sends the query to the database (setQuery) searches for these underscorings and replaces them with the prefix and as long as it does this anyway I thought it ok to replace them. Again something a more experienced developer would have a better solution for. My goal is just to make a working implementation for the next Joomla version and to leave the finetuning to someone that knows about it. 

Hackwar

Just keep coding
As long as it works and can be used not too difficultly (didn't want to say easily..) asap, many people will.
Good to see things moving

Maybe the next statement would be the correct statement, reflecting more precisely the original code, and working better (as the LEFT JOIN is referring to 'a', and a not being defined, the first implementation would not work correctly on the join):


Looked more in detail, good work on that file !

Any plans for the updated gacl_api.class.php file ? as I understand it's needed for a backend ACL admin interface.

We need to look at the next steps... what are your plans ? ...what are the core team's plans ?

If your target is Joomla 1.1, you should be able to use adodb since it's part of 4.5.3. Make sure this really is the plan of the core team.
Masterchief has already written something to manage users, you should ask him if it's on the cvs somewhere, it would be better to finish his work instead of starting a new one if you go in the same direction.

I'm working on a ACL-implementation and because I've got a week left before my studies start I will work as fast as I can. I hope I get done in a week.
The api.class is needed and is in progress.
There will be problems with the database. I think I will have to alter some vital tables like _users, _content and _menu to get a unique identifier for the ACO-entrys. I don't know if this is what the developer team wants. I know from other projects, that they don't like such steps. Lets see what they say.


I tried to contact masterchief by pm but my messages get rejected. While Mambo 4.5.3 is this alpha and I think Joomla is supposed to be stable when it is released, I will hang on the current database-handling. The changes to get it back to ADODB are minor and can be done in a few hours. The admin-interface and the correct implementation into the other components and modules is way more work and more difficult than the actual ACL-class.
I hope to hear from the development team as soon as I have something usable, because, lets be true, the work I've done till now is allmost nothing. In the last 5 hours I allmost exclusively tried to understand the structures behind Joomla and phpGACL.
As I said, I hope to get some stuff done in the next days.
Hackwar

Yes, changing core tables is...core team's task. Strongly unrecommended.

There is a table in 4.5.2/1.0 called #__core_acl_aro which links userIds with AROs (btw, the core 4.5.2 forgets to delete entries into that table when a user is deleted ). So I think that #__users table doesn't need a change.

A similar intermediate table can be designed for _content, _menu and other tables needing *optionally* an ACO/AXO assigned.

Do we really need unique identifiers for _content, _menu etc for the ACO entries (btw they already have each, one) ?

A better way I think would be the admin to define abstract access objects and projects (i.e. ACO/AXO) in the backend, which reflect his business model (we still can define default values as I suggested previously) and then for each item (content, menu) to assign *optionally* a ACO (and optionally a AXO).

We need to think in terms of permissions, it's better to have a view from the permissions-angle, like it's done in the SF that we use here, then for each item. Also, it will allow for a separate role (i.e. ARO-group) "Security/Access Officer" for managing the accesses, instead of the article/menu authors.

In that way, we get: no modifications to the existing J! 1.0-database tables, and a better usability added to more simplicity, without compromising flexibility . Assigning and managing single ACOs to each item would be to painful for the site admin.

Other advantage is that 3PD components could just offer a list of items needing access protection (with a new API) to the access-protection management in the backend, which would then offer to set a choice of existing ACO for each of them (depending on the level of the admin in the backend of course).

But again, I know that Eddie has done some thoughts also on this, so it would be good to have his input as well, and to coordinate with core-team (you may can also try to contact Rey (stingrey), since Andrew's inbox is quite full these days ).

Are these thoughts going in same direction as your plans ?...as core team plans ? as Community's wishes ?  other feedbacks welcome also...

I saw those allready and will look what can be done to implement these. There are quite a lot of tables the phpgacl needs, but some of them seem to be merged from tables that are fundamentaly different in the original phpgacl. I can't tell you more, cause I'm quite frankly tired. Its 1:20 am in germany atm and my concentration is going to bed. 


The idea was to make everything in Joomla ACL-able. The access-requesting function, no matter if its in a 3PD component or in a core-component, gives the ACL-lib the unique ID of the ARO and the ACO and this function has to get its ID from somewhere. I don't know if its whise to create this out of the title of the item, because you could have sections, categories and articles with the same name and therefore the same ID... unless you put the descriptor for that kind of item in front of it... got that "idea" this second and it will most probably be possible, but needs more thinking. My inital idea was, that different tables with sequentially numbered entrys can have duplicate IDs...

Hackwar