Archived

Access Control System In Joomla 1.6

From Joomla! Documentation

Revision as of 03:59, 20 September 2010 by Batch1211 (talk | contribs)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This page has been archived. This page contains information for an unsupported Joomla! version or is no longer relevant. It exists only as a historical reference, it will not be improved and its content may be incomplete and/or contain broken links.

Template:Future

Note:Please note that much of the information in this document is out of date.

This is a pre alpha document Joomla! version 1.6 that shows early concepts 
not all of which are implemented in 1.6. Since version 1.6 is still under 
active development, screenshots and other information discussed in this 
article may change before the final release of version 1.6. However, 
it is expected that the basic concepts outlined here will not change.


Overview[edit]

Sections[edit]

Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.

Users[edit]

These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system. Users can be mapped to rules via jos_user_rule_map table. In phpGACL, users were called AROs (Access Request Object).

User Groups[edit]

These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map. User groups can be mapped to rules via the jos_usergroup_rule_map table.

Actions[edit]

Actions are things your users will perform such as logging in to backend.

Actions have dependencies and precedence. For example, setting a group Admin rights will take precedence over lesser actions such as login. Thus, if a group has admin set to allow, you cannot deny them the ability to login.

Assets[edit]

Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.

Asset Groups[edit]

These are used for creating different view permissions for a combination of usergroups. (???) How this is achieved:

  • First a view action is created with access type 3. (eg. core.view)
  • Then an asset group is created with some user groups in it.
  • A rule is set with the name convention {action_name}.{asset_group_id} (eg. core.view.1 for Public)
  • action, assetgroup and user groups are all mapped to this rule.
  • When three of them map to the same rule then JUser::getAuthorisedLevels() will also return the new asset group id.

Rules[edit]

Rules are combinations of actions and usergroups (or users) and optionally assets. There are three types of rules:

  • Type 1: These are rules that allow a user or user group to do an action. For example user group X can log in to backend.
  • Type 2: These are rules that allow a user or user group to do an action on an asset. For example user group X can edit an article with the id of Y.
  • Type 3: These are rules that allow a user or user group to do an action (mostly view) on an asset group. For example user group X can view articles with the asset group of Y. (???)

Library[edit]

TODO

Examples[edit]

Core Access Levels[edit]

There are three access levels in core by default: Public, Registered, Special. These are access levels. For them we use the action core.view. Let's use Special for our example: First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is core.view.3. As you remember naming convention is action_name.asset_group_id and here our id is 3.

Database tables[edit]

It seems that this diagram has been deprecated in favor of much simpler structure.

  • jos_assets: id, parent_id, lft, rgt, level, name, title, rules
  • jos_usergroups: id, parent_id, lft, rgt, title
  • jos_user_usergroup_map: user_id, group_id
  • jos_viewlevels: id, title, ordering, rules
  • jos_categories and jos_content contain foreign key asset_id
  • Rules field is a JSON encoded string with content like this: '{"core.admin":{"7":1},"core.manage":{"6":1}}'

-- Matias 7-Mar-2010

File:Dia acl base.png