Welcome, Guest
Username: Password: Remember me

TOPIC: ACL in joomla. sharing ideas

ACL in joomla. sharing ideas 04 Aug 2014 07:37 #12568

  • Tomaselli
  • Tomaselli's Avatar
  • Offline
  • Elite Member
  • Posts: 293
  • Thank you received: 87
  • Karma: 46
Hi jcook community,
It has been a while from my last post, I've been too busy in the last months.

I was wondering what your ideas are about the ACL system in joomla. In particular way I'm talking about the asset table and the access field on each item record.

Scenario:
- item level ACL enabled (jtable upgraded with all the necessary functions, access.xml modified, item_form.xml modified, etc. etc.)

I'd like to know your thoughts about:
1) why the asset rules are not stored in the record itself?
(right now only the asset_id is stored, and the jtable gets ans sets the rules into the #__assets).
shouldn't it be better to store those rules directly into the item record?

2) Why the "access" rules are separated from the ACL rules?
To me it would make much more sense to just have the asset rules including the VIEW rules

Anyone who would share his/her thoughts is very welcome.
The administrator has disabled public write access.

ACL in joomla. sharing ideas 05 Aug 2014 13:08 #12572

  • admin
  • admin's Avatar
  • Offline
  • Administrator
  • Chef
  • Posts: 3711
  • Thank you received: 984
  • Karma: 140
Hi Tomaselli... Happy to see you back !
I was quite away too last months. but I am now back on tracks.

I understand what you mean.
Then it will include the whole permissions table in the item itself. I think this is very good idea, I must ckeck how to code it.
Also I should put it as an option, because the way you describe will may take more time to configure, than simply the use of a access group for view.
With your method (wich is common in Joomla), it would be possible to manage specific ACL for specific object. It is the goal in future. And I think Joomla should handle that quite easy. I must check closer...
Coding is now a piece of cake
The administrator has disabled public write access.

ACL in joomla. sharing ideas 06 Aug 2014 07:21 #12579

  • Tomaselli
  • Tomaselli's Avatar
  • Offline
  • Elite Member
  • Posts: 293
  • Thank you received: 87
  • Karma: 46
Hi Admin,
I'm glad you replied to this post! I'm still a bit busy but hopefully I'll be free after the summer.
In the last week I had to take a close look to the whole ACL system and its related joomla PHP classes.
At the end it's quite simple but In my opinion there are few lacks in the possibilities, and surely it could be improved.

let's take the com_content access.xml as example:
<access component="com_content">
  <section name="component">
	<action name="core.admin" title="JACTION_ADMIN" description="JACTION_ADMIN_COMPONENT_DESC" />
	<action name="core.manage" title="JACTION_MANAGE" description="JACTION_MANAGE_COMPONENT_DESC" />
	<action name="core.create" title="JACTION_CREATE" description="JACTION_CREATE_COMPONENT_DESC" />
	<action name="core.delete" title="JACTION_DELETE" description="JACTION_DELETE_COMPONENT_DESC" />
	<action name="core.edit" title="JACTION_EDIT" description="JACTION_EDIT_COMPONENT_DESC" />
	<action name="core.edit.state" title="JACTION_EDITSTATE" description="JACTION_EDITSTATE_COMPONENT_DESC" />
	<action name="core.edit.own" title="JACTION_EDITOWN" description="JACTION_EDITOWN_COMPONENT_DESC" />
   </section>
   <section name="category">
	<action name="core.create" title="JACTION_CREATE" description="COM_CATEGORIES_ACCESS_CREATE_DESC" />
	<action name="core.delete" title="JACTION_DELETE" description="COM_CATEGORIES_ACCESS_DELETE_DESC" />
	<action name="core.edit" title="JACTION_EDIT" description="COM_CATEGORIES_ACCESS_EDIT_DESC" />
	<action name="core.edit.state" title="JACTION_EDITSTATE" description="COM_CATEGORIES_ACCESS_EDITSTATE_DESC" />
	<action name="core.edit.own" title="JACTION_EDITOWN" description="COM_CATEGORIES_ACCESS_EDITOWN_DESC" />
   </section>
   <section name="article">
	<action name="core.delete" title="JACTION_DELETE" description="COM_CONTENT_ACCESS_DELETE_DESC" />
	<action name="core.edit" title="JACTION_EDIT" description="COM_CONTENT_ACCESS_EDIT_DESC" />
	<action name="core.edit.state" title="JACTION_EDITSTATE" description="COM_CONTENT_ACCESS_EDITSTATE_DESC" />
   </section>
</access>

1) sections.
the category and the article sections are just "item level" rules because categories are managed by the com_categories and the relative assets are stored in the #__assets table as single category asset.

in my opinion, the parent sections (other than component) are completely missing.
In this scenario a section "categories" (and an "articles" section) with parent "component" is missing.
Moreover there is no way to configure it through the "config" of the component, because the input field type "rules" (in config.xml) and the com_config don't manage sections other than component.


2) item level asset.
the item level is stored in the #__assets table. so it means:
a) when I load OR save the item I make 2 DB calls (1 for the item itself, 1 for the assets in the #__assets table)
b) if I have 1 millions of articles, I would have 1 millions of rows in #__content and more than that in #__assets,


3) access and asset_id
the access field is used for VIEW access to the item, but it's nothing else than an ACL rule, so why not use it in the standard ACL system as rule?


my suggestions and workaround:
1) in the component config.xml it would be possible to configure the "main parent" "component" section and childs sections, one for each component table in DB (in this scenario: categories, articles).
this will allow us to deeply configure items in categories and articles and eventually use the "main parent" "component" when a rule is not found or inherited in the subsection. In this way also an "item level" ACL system would have benefit, because the single article or category would have its own section as parent asset rules.


2) there is no need in my opinion to keep the assets rules in a separate table. the assets rules can just be stored in the item itself, so instead of a field "asset_id" for a foreign key I would just have an "asset" field with all the rules stored.
this will avoid extra DB calls and HDD space wasted. Moreover it would be easier to do some search in the DB.


3) There is no need of "access" and "asset_id" (or asset with all the rules). I would just use the "asset" field, and store all the ACL rules including also the "core.view.item" rule, (I made a post for 2 new rules I'm already using in few projects check this post)



I've almost implemented all these features, but for my needs. it's not that difficult, I took a couple of days to read the joomla ACL, the PHP classes and to assimilate the information, then half day to implement them for my needs.
I have to complete some projects I'm working on, then I'll clean up the code and I'll send it to you, I think there is no urgency for these new features.
I hope to have been enough clear, I talked assuming we all know what we are talking about, but if something is not clear, please tell me.
Last Edit: 06 Aug 2014 07:23 by Tomaselli.
The administrator has disabled public write access.
Time to create page: 0.086 seconds

Get Started