Joomla! :: View topic - Joomla ACL enhancments

what users and or user groups have access to certain components

How about specific content on a page when content is created?

everyone to be able to read an article except the last paragraph

Quote:

everyone to be able to read an article except the last paragraph

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

Hope this helps.

Quote:

what users and or user groups have access to certain components

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.

How about specific content on a page when content is created?

masterchief wrote:

Quote:

everyone to be able to read an article except the last paragraph

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

- ARO (Access Request Object) is typically a user
- ARO Group is typically a group of users (a user can be part of multiple groups)
- ACO (Access Control Object) is typically either a type of content or actions to control access onto
- AXO (Access eXtension Objects) are typically an optional additional typing of access (e.g. full site or a given project, etc)
The usage can vary from the above, but what ACL does is basically:
1) define which ARO belong to which ARO Groups
2) define which ARO groups are allowed access to which ACO (for a given AXO if defined)
3) provide a simple function allowing for components to check if a ARO has access to a ACO or ACO/AXO.

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.

phpGACL is already included in Joomla!

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

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.

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

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:

Code:

SELECT      a.id,a.allow,a.return_value
FROM      '. $this->_db_table_prefix .'acl a
LEFT JOIN    '. $this->_db_table_prefix .'aco_map ac ON ac.acl_id=a.id';

Code:

SELECT id, allow, return_value
FROM      #__acl 
LEFT JOIN    #__aco_map ac ON ac.acl_id=a.id';

- 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.

- this change seems strange and maybe reviewed:

Code:

SELECT      a.id,a.allow,a.return_value
FROM      '. $this->_db_table_prefix .'acl a
LEFT JOIN    '. $this->_db_table_prefix .'aco_map ac ON ac.acl_id=a.id';

Code:

SELECT id, allow, return_value
FROM      #__acl 
LEFT JOIN    #__aco_map ac ON ac.acl_id=a.id';

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.

...
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-entries. 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.
...
Hackwar

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) ?

Author:	paulsjv [ Fri Sep 02, 2005 7:41 pm ]
Post subject:	Joomla ACL enhancments
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!

Author:	masterchief [ Sat Sep 03, 2005 10:29 am ]
Post subject:	Re: Joomla ACL enhancments
Quote: what users and or user groups have access to certain components 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. Quote: How about specific content on a page when content is created? 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: everyone to be able to read an article except the last paragraph Hrm, that would not be easy but I would imagine you could craft a mambot to emmulate that. Hope this helps.

Author:	SineMacula [ Sat Sep 03, 2005 10:53 pm ]
Post subject:	Re: Joomla ACL enhancments
masterchief wrote: Quote: everyone to be able to read an article except the last paragraph 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

Author:	paulsjv [ Tue Sep 06, 2005 7:30 pm ]
Post subject:	Re: Joomla ACL enhancments
First, thank you masterchief for your reply! This is exactly what I was looking for. masterchief wrote: Quote: what users and or user groups have access to certain components 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. 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"\] Quote: How about specific content on a page when content is created? 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.

Author:	paulsjv [ Tue Sep 06, 2005 7:31 pm ]
Post subject:	Re: Joomla ACL enhancments
SineMacula wrote: masterchief wrote: Quote: everyone to be able to read an article except the last paragraph 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 Ah yes! I remember reading about mosIF. There's just so much to keep track of it's easy to forget things. $:-\$

Joomla! http://forum.joomla.org/

Joomla ACL enhancments http://forum.joomla.org/viewtopic.php?f=126&t=3391	Page 1 of 9

Author:	Beat [ Tue Sep 13, 2005 9:33 am ]
Post subject:	Re: Joomla ACL enhancments
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): Quote: - ARO (Access Request Object) is typically a user - ARO Group is typically a group of users (a user can be part of multiple groups) - ACO (Access Control Object) is typically either a type of content or actions to control access onto - AXO (Access eXtension Objects) are typically an optional additional typing of access (e.g. full site or a given project, etc) The usage can vary from the above, but what ACL does is basically: 1) define which ARO belong to which ARO Groups 2) define which ARO groups are allowed access to which ACO (for a given AXO if defined) 3) provide a simple function allowing for components to check if a ARO has access to a ACO or ACO/AXO. 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 .

Author:	masterchief [ Tue Sep 13, 2005 10:33 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Beat [ Wed Sep 14, 2005 5:12 pm ]
Post subject:	Re: Joomla ACL enhancments
masterchief wrote: 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

Author:	chiky [ Wed Sep 21, 2005 10:26 pm ]
Post subject:	Re: Joomla ACL enhancments
I'm agree with Beat. let us know how we can help you guys to have a good basic implementation on 1.1 soon.

Author:	Hackwar [ Fri Sep 23, 2005 3:40 pm ]
Post subject:	Re: Joomla ACL enhancments
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

Author:	chiky [ Fri Sep 23, 2005 3:42 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Fri Sep 23, 2005 3:50 pm ]
Post subject:	Re: Joomla ACL enhancments
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

Author:	Beat [ Fri Sep 23, 2005 4:05 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Fri Sep 23, 2005 5:05 pm ]
Post subject:	Re: Joomla ACL enhancments
Beat wrote: phpGACL is already included in Joomla! 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... Quote: The problem is not including phpGACL but: step 1: configuring the default settings it the right way (not only groups, but all the rest) Why not just take the standard values? Mambo must have worked with some values up till now. Quote: step 2: allowing the admin to define all ACL objects and access rights 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.

Page 1 of 9	All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/

Author:	chiky [ Fri Sep 23, 2005 7:14 pm ]
Post subject:	Re: Joomla ACL enhancments
Hackwar if I can help you with something just let me know.

Author:	gizmola [ Fri Sep 23, 2005 10:14 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Fri Sep 23, 2005 10:25 pm ]
Post subject:	Re: Joomla ACL enhancments
gizmola wrote: 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....

Author:	gizmola [ Sat Sep 24, 2005 1:05 am ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Sat Sep 24, 2005 10:21 am ]
Post subject:	Re: Joomla ACL enhancments
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

Author:	Hackwar [ Sat Sep 24, 2005 11:53 am ]
Post subject:	Re: Joomla ACL enhancments
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....

Author:	interfaSys [ Sun Sep 25, 2005 12:08 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Sun Sep 25, 2005 1:25 pm ]
Post subject:	Re: Joomla ACL enhancments
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

Author:	Beat [ Sun Sep 25, 2005 8:24 pm ]
Post subject:	Re: Joomla ACL enhancments
Hackwar wrote: 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 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: Code: SELECT a.id,a.allow,a.return_value FROM '. $this->_db_table_prefix .'acl a LEFT JOIN '. $this->_db_table_prefix .'aco_map ac ON ac.acl_id=a.id'; Code: SELECT id, allow, return_value FROM #__acl LEFT JOIN #__aco_map ac ON ac.acl_id=a.id'; - 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.

Author:	Hackwar [ Sun Sep 25, 2005 9:04 pm ]
Post subject:	Re: Joomla ACL enhancments
Beat wrote: 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). 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. Quote: Two feedbacks: - this change seems strange and maybe reviewed: Code: SELECT a.id,a.allow,a.return_value FROM '. $this->_db_table_prefix .'acl a LEFT JOIN '. $this->_db_table_prefix .'aco_map ac ON ac.acl_id=a.id'; Code: SELECT id, allow, return_value FROM #__acl LEFT JOIN #__aco_map ac ON ac.acl_id=a.id'; - 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. 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

Author:	eyezberg [ Sun Sep 25, 2005 9:27 pm ]
Post subject:	Re: Joomla ACL enhancments
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

Author:	Beat [ Sun Sep 25, 2005 9:33 pm ]
Post subject:	Re: Joomla ACL enhancments
Beat wrote: - this change seems strange and maybe reviewed: Code: SELECT a.id,a.allow,a.return_value FROM '. $this->_db_table_prefix .'acl a LEFT JOIN '. $this->_db_table_prefix .'aco_map ac ON ac.acl_id=a.id'; Code: SELECT id, allow, return_value FROM #__acl LEFT JOIN #__aco_map ac ON ac.acl_id=a.id'; 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): Code: SELECT a.id, a.allow, a.return_value FROM #__acl a LEFT JOIN #__aco_map ac ON ac.acl_id=a.id'; 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 ?

Author:	interfaSys [ Sun Sep 25, 2005 9:34 pm ]
Post subject:	Re: Joomla ACL enhancments
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.

Author:	Hackwar [ Sun Sep 25, 2005 10:07 pm ]
Post subject:	Re: Joomla ACL enhancments
Beat wrote: 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 ? 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. interfaSys wrote: 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 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

Author:	Beat [ Sun Sep 25, 2005 10:46 pm ]
Post subject:	Re: Joomla ACL enhancments
Hackwar wrote: ... 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-entries. 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. ... 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...

Author:	Hackwar [ Sun Sep 25, 2005 11:36 pm ]
Post subject:	Re: Joomla ACL enhancments
Beat wrote: 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. 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. Quote: Do we really need unique identifiers for _content, _menu etc for the ACO entries (btw they already have each, one) ? 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