? Failure

User tests: Successful: Unsuccessful:

avatar jmcameron
jmcameron
12 Apr 2013

Default Component ACL Rules

Joomla Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30550 (submitted for both Joomla 2.5 and 3.x)

Background / Motivation

There is currently no easy way to specify the default action permission rules
for a component that has component-specific custom permission rules. If
component developers want default ACL rules for their custom ACL rules, they
must create code that modifies the root asset. This is extra work for
component developers and a potential source of errors and problems.

Proposed Fix

The proposed fix addresses this problem by extending the syntax of component
'access.xml' file that lists the component-specific ACL rules. The goal is to
allow the component developer to specify the groups that should be allowed to
perform the ACL action as part of the XML definition for each ACL rule. This
would require updates to Joomla (the platform) to interpret the additions to
the 'access.xml' and add the appropriate permissions to the system.

The proposed function provides new functions to install or remove the default
permissions specified in the 'access.xml' file. Normally this would be done
in by the installer by having the component installer call the new function
during installation. In the following description, assume the new function is
called by the installer.

These additions will be backwards compatible since the additional XML
attributes will be ignored by versions of Joomla that have not implemented
this fix.

Since there are many different ways that a particular component can implement
ACL rules, a few guiding principles are necessary:

  1. If the default for a custom ACL rule is not specified, the default root
    ACL rules will not be modified. This is the current behavior.
  2. If the group with the specified permssions in the default rules does not
    exist in the Joomla installation, no root permission will be set and an
    information message will be generated. Some Joomla installations have
    been known to delete all common groups (such as Public, Registered) and
    create new groups. So there is no guarantee that normally expected groups
    will exist.
  3. The component developer will specify a component (usually com_content)
    and an action to check and the installer will find a group with that
    permission. The component developer may give a suggestion for which
    group to check first. If the group is found and has the required
    permissions, then it will be used. Otherwise the installer will search
    for a suitable group with the required permissions. All groups will be
    checked and the one with the least authority will be used (eg, if both
    Author and Publisher have the required permission, Author will be chosen
    since Publisher has more authority).
  4. This new feature would only be applied to any custom component-specific
    rule in a components 'access.xml'. This approach cannot be used to
    modify the core rules in the root rule.

Example 'access.xml' syntax additions

The following syntax change is proposed. In the following examples, the
component for the 'access.xml' file is 'com_example':

Notice the new 'default' attribute at the end. The groups will be searched to
find the least authoritative group that has the 'core.delete' permission for
com_content (for instance, delete example items they created). This will mean
that all derived groups also have this permission.

Note that this could be a comma-separated list of group names.

The component developer could also specify a hint on which group to check
first:

In this case, the installer would first check to see if the 'Author' group has
the required permission. If it does, it would be used. If not, no warning
message would be given and the search for a group with that permission would
continue.

Note that the test component could be something other than 'com_content':

Which would find a group that has permission to do 'core.delete' for the
'com_xyz123' component. This could be used to synchronize default permissions
between two related components.

Testing the new functionality

A test component 'com_permtest' is available on github:

https://github.com/jmcameron/component_permissions_test

This includes a zipped up version of the component that is ready to install.

comp_permtest.zip

This test component should work on both Joomla 2.5.x and 3.x. Obviously the
functions will not do anything if the fixes to Joomla described here are not
implemented.

To try these fixes:

  • Install the fixes on your Joomla 2.5 or 3.x site (by doing 'git pull' or
    using a patch file)
  • Install the component in the regular way and then go to the
    'component-permissions-test' component under the 'Components' menu in the
    back end.
  • Read the instructions there on how to test it.

Note that these fixes include unit tests for the new capabilities (on the
Joomal 3.x version). See the bottom of the this document.

Implementation Notes

The functionality above is implemented by adding functions to JAccess and
JRules:

JRules::removeActions($action_regexp)

  • Remove all actions from the rule whose action name matches the regular
    expression. This a general function and could be used to remove core
    actions from the root rule, if the calling code requested it (not
    recommended).

JAccess::getGroupId($groupname)

  • Returns a group ID for the given group name.
  • This could be moved elsewhere, but there did not seem to be a suitable
    place. We may want to add a JUserGroup class (in
    libraries/joomla/user/group.php) and move this function into that class.

JAccess::removeDescendentGroups($groupIds)

  • Removes all groups in the provided set of groups that have ancestors in the
    set of groups. This is part of the code that helps select the least
    authoritative group since it eliminates children of groups that are already
    in the set since the child group is likely to have more permissions than
    its parent group.

JAccess::leastAuthoritativeGroup($groupIds, $asset)

  • Selects the least authoritative group out of a set of groups.
    Read the code for a clearer idea of how this works.

JAccess::installComponentDefaultRules($component, $file = null)

  • Parse the rules for custom rules in component's 'access.xml' file and
    install new permissions in the root asset, as needed.
  • Does not allow modifying core rules.
  • If a group with the required permission is not found or the group name
    specified in the hint part is unknown by the Joomla installation, the
    default specified will be ignored. Currently a log message is being added.
    This should probably be a JApplication::enqueueMessage() call but I could
    not get that to work in the unit tests.
  • This function can be called any time, but it would make sense to call this
    during component installation in the postflight section.
  • The optional $file can be used to specify an alternate location for the
    'acess.xml' file (for testing).

JAccess::purgeComponentDefaultRules($component)

  • Removes all custom rules for $component defined in the root asset.
  • Core rules will not be modified.
  • This function can be called at any time, but it would make sense to call
    this during the uninstallation of a component (during preflight or the
    uninstall function).

Unit tests

  • Unit tests for Joomla 3 that cover the features above have been added to
    the tests/unit/suites/libraries/access folder.
  • The custom unit test configuration file
    tests/system/servers/configdef.php was added to the toplevel .gitignore
    since it could contain private data and should be ignored (like .gitignore
    already ignores the top-level phpunit config file phpunit.xml).

Jonathan Cameron
April 28, 2013

avatar jmcameron jmcameron - open - 12 Apr 2013
avatar jmcameron
jmcameron - comment - 19 Apr 2013

Based on some feedback from Elin, I am reworking this to be more flexible/robust (see #976). Here is what I'm working on now:

Change the syntax/semantics for specifying the default in the access.xml file to this:

  defaults="com_content:core_create[Author]"

So this enables the permission for the rule involved if it can find a group that perform 'core_create' for the 'com_content' component. The optional 'Author' in brackets at the end is a hint of what group try first. It will check to see if that group has the required permission. If so, it will use it. If not, it will search through the groups to find all groups that have the desired permission and then select the one that is the least privileged (closest to the root group).

-Jonathan

avatar jmcameron
jmcameron - comment - 24 Apr 2013

I am working on refactoring this and will do a new pull request or reopen this one when I'm ready.

-Jonathan

avatar jmcameron jmcameron - close - 24 Apr 2013
avatar jmcameron
jmcameron - comment - 29 Apr 2013

Completed refactoring this to accept the changed syntax for the defaults discussed above. Updated documentation for the issue and fix above. To see the old documentation see the files attached to the joomlacode tracker page http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30550 (See DefaultPermissions-OLD.pdf). The new documentation above is also in the updated DefaultPermissions-VERSION2.pdf on the tracker page. The tracker page also includes new patch files and test component zip file.

Re-opening pull request.

P.S. @elinw @sanderpotjer This is now ready to review and test.

avatar jmcameron jmcameron - reopen - 29 Apr 2013
avatar jmcameron
jmcameron - comment - 18 Aug 2013

Elin and @sanderpotjer,

I thought that my (somewhat arbitrary) ranking seemed like a reasonable way to find a group that had the required permissions and not much more. In other words, an Admin will usually match any requirement. But if you had to choose between an Author and and Admin, you should choose the Author because you do not want to give users more permissions than they need.

Perhaps an alternate approach is just to count the number of extra privileges and choose a group that has the least number of extra privileges. If you have two groups that have the same number of extra privileges, I suppose we could select one at random.

I'm open to suggestions and I'm willing to rework this so it makes sense.

-Jonathan

avatar elinw
elinw - comment - 19 Aug 2013

I think you need to deal with the whole matrix exactly as it is rather than
trying to guess. Really I would suggest that you in general just match the
permissions for a given component as the simplest thing. Since com_content
is the only required core content type component I would generally just do
that for other content-like assets and maybe the com_modules permissions
for other things that aren't content but of course let the developer
pick. So really it is just a matter of copying that data from the assets
table to your new row in the assets table including updating with any
additional extension.action key value pair that you need. Overall most
actions are in essence the CRUD actions so I really have not seen a lot
of/any situations where any actions besides admin, manage, delete, edit,
edit.state, edit.own, create are necessary. The real issue is being able
to insert an additional necessary assets since as far as I know things like
adding an "uncategorized" category to the asset table still requires some
work. In addition many extensions do have different types of assets.
If you feel you absolutely must have extension.actions (i.e. that do not
inherit from global config as the fall back )(such a structure is quite a
pain for users but still you may have it because of a special situation in
your component) If you are doing that, i'd just suggest saying, ok what is
core.edit.own for this group, let's by default apply the same for our new
action extension.custom_action.own.

I really think it is important to remember that each new action is a
geometric increase in the complexity of processing.

On Sun, Aug 18, 2013 at 5:30 PM, Jonathan Cameron
notifications@github.comwrote:

Elin and @sanderpotjer https://github.com/sanderpotjer,

I thought that my (somewhat arbitrary) ranking seemed like a reasonable
way to find a group that had the required permissions and not much more. In
other words, an Admin will usually match any requirement. But if you had to
choose between an Author and and Admin, you should choose the Author
because you do not want to give users more permissions than they need.

Perhaps an alternate approach is just to count the number of extra
privileges and choose a group that has the least number of extra
privileges. If you have two groups that have the same number of extra
privileges, I suppose we could select one at random.

I'm open to suggestions and I'm willing to rework this so it makes sense.

-Jonathan

—
Reply to this email directly or view it on GitHub#975 (comment)
.

avatar nicksavov
nicksavov - comment - 26 Aug 2013

Hi Jonathan,

It's out-of-sync with master. Could you re-sync it please?

avatar jmcameron
jmcameron - comment - 27 Aug 2013

Synced up. Thanks.

@elinw Thanks for the inputs. I haven't had a chance to look at this due to travel, etc. I'll try to get back to it in the next couple of days.

-Jonathan

avatar jissues-bot
jissues-bot - comment - 24 Jan 2014

Pull requests to the master branch of this repo are not accepted. Please close this pull request and submit a new one against the staging branch.

avatar jmcameron jmcameron - change - 3 Mar 2014
Title
Default Component ACL Rules (3.x)
[#30550] Default Component ACL Rules (3.x)
avatar brianteeman brianteeman - change - 8 Aug 2014
Description <h1>Default Component ACL Rules</h1> <p>Joomla Tracker: <a href="http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&amp;tracker_item_id=30550">http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&amp;tracker_item_id=30550</a> (submitted for both Joomla 2.5 and 3.x)</p> <h2>Background / Motivation</h2> <p>There is currently no easy way to specify the default action permission rules<br> for a component that has component-specific custom permission rules. If<br> component developers want default ACL rules for their custom ACL rules, they<br> must create code that modifies the root asset. This is extra work for<br> component developers and a potential source of errors and problems.</p> <h2>Proposed Fix</h2> <p>The proposed fix addresses this problem by extending the syntax of component<br> 'access.xml' file that lists the component-specific ACL rules. The goal is to<br> allow the component developer to specify the groups that should be allowed to<br> perform the ACL action as part of the XML definition for each ACL rule. This<br> would require updates to Joomla (the platform) to interpret the additions to<br> the 'access.xml' and add the appropriate permissions to the system. </p> <p>The proposed function provides new functions to install or remove the default<br> permissions specified in the 'access.xml' file. Normally this would be done<br> in by the installer by having the component installer call the new function<br> during installation. In the following description, assume the new function is<br> called by the installer.</p> <p>These additions will be backwards compatible since the additional XML<br> attributes will be ignored by versions of Joomla that have not implemented<br> this fix.</p> <p>Since there are many different ways that a particular component can implement<br> ACL rules, a few guiding principles are necessary:</p> <ol> <li><p>If the default for a custom ACL rule is not specified, the default root<br> ACL rules will not be modified. This is the current behavior.</p></li> <li><p>If the group with the specified permssions in the default rules does not<br> exist in the Joomla installation, no root permission will be set and an<br> information message will be generated. Some Joomla installations have<br> been known to delete all common groups (such as Public, Registered) and<br> create new groups. So there is no guarantee that normally expected groups<br> will exist.</p></li> <li><p>The component developer will specify a component (usually com_content)<br> and an action to check and the installer will find a group with that<br> permission. The component developer may give a suggestion for which<br> group to check first. If the group is found and has the required<br> permissions, then it will be used. Otherwise the installer will search<br> for a suitable group with the required permissions. All groups will be<br> checked and the one with the least authority will be used (eg, if both<br> Author and Publisher have the required permission, Author will be chosen<br> since Publisher has more authority).</p></li> <li><p>This new feature would only be applied to any custom component-specific<br> rule in a components 'access.xml'. This approach cannot be used to<br> modify the core rules in the root rule.</p></li> </ol><h2>Example 'access.xml' syntax additions</h2> <p>The following syntax change is proposed. In the following examples, the<br> component for the 'access.xml' file is 'com_example':</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_content:core.delete"</span> <span class="nt">/&gt;</span> </pre></div> <p>Notice the new 'default' attribute at the end. The groups will be searched to<br> find the least authoritative group that has the 'core.delete' permission for<br> com_content (for instance, delete example items they created). This will mean<br> that all derived groups also have this permission.</p> <p>Note that this could be a comma-separated list of group names.</p> <p>The component developer could also specify a hint on which group to check<br> first:</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_content:core.delete[Author]"</span> <span class="nt">/&gt;</span> </pre></div> <p>In this case, the installer would first check to see if the 'Author' group has<br> the required permission. If it does, it would be used. If not, no warning<br> message would be given and the search for a group with that permission would<br> continue.</p> <p>Note that the test component could be something other than 'com_content':</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_xyz123:core.delete"</span> <span class="nt">/&gt;</span> </pre></div> <p>Which would find a group that has permission to do 'core.delete' for the<br> 'com_xyz123' component. This could be used to synchronize default permissions<br> between two related components.</p> <h2>Testing the new functionality</h2> <p>A test component 'com_permtest' is available on github:</p> <p><a href="https://github.com/jmcameron/component_permissions_test">https://github.com/jmcameron/component_permissions_test</a></p> <p>This includes a zipped up version of the component that is ready to install.</p> <p>comp_permtest.zip</p> <p>This test component should work on both Joomla 2.5.x and 3.x. Obviously the<br> functions will not do anything if the fixes to Joomla described here are not<br> implemented.</p> <p>To try these fixes:</p> <ul> <li><p>Install the fixes on your Joomla 2.5 or 3.x site (by doing 'git pull' or<br> using a patch file)</p></li> <li><p>Install the component in the regular way and then go to the<br> 'component-permissions-test' component under the 'Components' menu in the<br> back end.</p></li> <li><p>Read the instructions there on how to test it.</p></li> </ul><p>Note that these fixes include unit tests for the new capabilities (on the<br> Joomal 3.x version). See the bottom of the this document.</p> <h2>Implementation Notes</h2> <p>The functionality above is implemented by adding functions to JAccess and<br> JRules:</p> <p><strong>JRules::removeActions($action_regexp)</strong></p> <ul> <li>Remove all actions from the rule whose action name matches the regular expression. This a general function and could be used to remove core actions from the root rule, if the calling code requested it (not recommended).</li> </ul><p><strong>JAccess::getGroupId($groupname)</strong></p> <ul> <li><p>Returns a group ID for the given group name.</p></li> <li><p>This could be moved elsewhere, but there did not seem to be a suitable<br> place. We may want to add a JUserGroup class (in<br> libraries/joomla/user/group.php) and move this function into that class.</p></li> </ul><p><strong>JAccess::removeDescendentGroups($groupIds)</strong></p> <ul> <li>Removes all groups in the provided set of groups that have ancestors in the set of groups. This is part of the code that helps select the least authoritative group since it eliminates children of groups that are already in the set since the child group is likely to have more permissions than its parent group.</li> </ul><p><strong>JAccess::leastAuthoritativeGroup($groupIds, $asset)</strong></p> <ul> <li>Selects the least authoritative group out of a set of groups.<br> Read the code for a clearer idea of how this works.</li> </ul><p><strong>JAccess::installComponentDefaultRules($component, $file = null)</strong></p> <ul> <li><p>Parse the rules for custom rules in component's 'access.xml' file and<br> install new permissions in the root asset, as needed.</p></li> <li><p>Does not allow modifying core rules.</p></li> <li><p>If a group with the required permission is not found or the group name<br> specified in the hint part is unknown by the Joomla installation, the<br> default specified will be ignored. Currently a log message is being added.<br> This should probably be a JApplication::enqueueMessage() call but I could<br> not get that to work in the unit tests.</p></li> <li><p>This function can be called any time, but it would make sense to call this<br> during component installation in the postflight section.</p></li> <li><p>The optional $file can be used to specify an alternate location for the<br> 'acess.xml' file (for testing).</p></li> </ul><p><strong>JAccess::purgeComponentDefaultRules($component)</strong></p> <ul> <li><p>Removes all custom rules for $component defined in the root asset.</p></li> <li><p>Core rules will not be modified.</p></li> <li><p>This function can be called at any time, but it would make sense to call<br> this during the uninstallation of a component (during preflight or the<br> uninstall function).</p></li> </ul><h2>Unit tests</h2> <ul> <li><p>Unit tests for Joomla 3 that cover the features above have been added to<br> the <em>tests/unit/suites/libraries/access</em> folder.</p></li> <li><p>The custom unit test configuration file<br><strong>tests/system/servers/configdef.php</strong> was added to the toplevel .gitignore<br> since it could contain private data and should be ignored (like .gitignore<br> already ignores the top-level phpunit config file <strong>phpunit.xml</strong>).</p></li> </ul><p>Jonathan Cameron<br><br> April 28, 2013</p> <h1>Default Component ACL Rules</h1> <p>Joomla Tracker: <a href="http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&amp;tracker_item_id=30550">http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&amp;tracker_item_id=30550</a> (submitted for both Joomla 2.5 and 3.x)</p> <h2>Background / Motivation</h2> <p>There is currently no easy way to specify the default action permission rules<br> for a component that has component-specific custom permission rules. If<br> component developers want default ACL rules for their custom ACL rules, they<br> must create code that modifies the root asset. This is extra work for<br> component developers and a potential source of errors and problems.</p> <h2>Proposed Fix</h2> <p>The proposed fix addresses this problem by extending the syntax of component<br> 'access.xml' file that lists the component-specific ACL rules. The goal is to<br> allow the component developer to specify the groups that should be allowed to<br> perform the ACL action as part of the XML definition for each ACL rule. This<br> would require updates to Joomla (the platform) to interpret the additions to<br> the 'access.xml' and add the appropriate permissions to the system. </p> <p>The proposed function provides new functions to install or remove the default<br> permissions specified in the 'access.xml' file. Normally this would be done<br> in by the installer by having the component installer call the new function<br> during installation. In the following description, assume the new function is<br> called by the installer.</p> <p>These additions will be backwards compatible since the additional XML<br> attributes will be ignored by versions of Joomla that have not implemented<br> this fix.</p> <p>Since there are many different ways that a particular component can implement<br> ACL rules, a few guiding principles are necessary:</p> <ol class="task-list"> <li><p>If the default for a custom ACL rule is not specified, the default root<br> ACL rules will not be modified. This is the current behavior.</p></li> <li><p>If the group with the specified permssions in the default rules does not<br> exist in the Joomla installation, no root permission will be set and an<br> information message will be generated. Some Joomla installations have<br> been known to delete all common groups (such as Public, Registered) and<br> create new groups. So there is no guarantee that normally expected groups<br> will exist.</p></li> <li><p>The component developer will specify a component (usually com_content)<br> and an action to check and the installer will find a group with that<br> permission. The component developer may give a suggestion for which<br> group to check first. If the group is found and has the required<br> permissions, then it will be used. Otherwise the installer will search<br> for a suitable group with the required permissions. All groups will be<br> checked and the one with the least authority will be used (eg, if both<br> Author and Publisher have the required permission, Author will be chosen<br> since Publisher has more authority).</p></li> <li><p>This new feature would only be applied to any custom component-specific<br> rule in a components 'access.xml'. This approach cannot be used to<br> modify the core rules in the root rule.</p></li> </ol><h2>Example 'access.xml' syntax additions</h2> <p>The following syntax change is proposed. In the following examples, the<br> component for the 'access.xml' file is 'com_example':</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_content:core.delete"</span> <span class="nt">/&gt;</span> </pre></div> <p>Notice the new 'default' attribute at the end. The groups will be searched to<br> find the least authoritative group that has the 'core.delete' permission for<br> com_content (for instance, delete example items they created). This will mean<br> that all derived groups also have this permission.</p> <p>Note that this could be a comma-separated list of group names.</p> <p>The component developer could also specify a hint on which group to check<br> first:</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_content:core.delete[Author]"</span> <span class="nt">/&gt;</span> </pre></div> <p>In this case, the installer would first check to see if the 'Author' group has<br> the required permission. If it does, it would be used. If not, no warning<br> message would be given and the search for a group with that permission would<br> continue.</p> <p>Note that the test component could be something other than 'com_content':</p> <div class="highlight highlight-xml"><pre><span class="nt">&lt;action</span> <span class="na">name=</span><span class="s">"example.delete.own"</span> <span class="na">title=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN"</span> <span class="na">description=</span><span class="s">"COM_EXAMPLE_PERMISSION_DELETEOWN_DESC"</span> <span class="na">default=</span><span class="s">"com_xyz123:core.delete"</span> <span class="nt">/&gt;</span> </pre></div> <p>Which would find a group that has permission to do 'core.delete' for the<br> 'com_xyz123' component. This could be used to synchronize default permissions<br> between two related components.</p> <h2>Testing the new functionality</h2> <p>A test component 'com_permtest' is available on github:</p> <p><a href="https://github.com/jmcameron/component_permissions_test">https://github.com/jmcameron/component_permissions_test</a></p> <p>This includes a zipped up version of the component that is ready to install.</p> <p>comp_permtest.zip</p> <p>This test component should work on both Joomla 2.5.x and 3.x. Obviously the<br> functions will not do anything if the fixes to Joomla described here are not<br> implemented.</p> <p>To try these fixes:</p> <ul class="task-list"> <li><p>Install the fixes on your Joomla 2.5 or 3.x site (by doing 'git pull' or<br> using a patch file)</p></li> <li><p>Install the component in the regular way and then go to the<br> 'component-permissions-test' component under the 'Components' menu in the<br> back end.</p></li> <li><p>Read the instructions there on how to test it.</p></li> </ul><p>Note that these fixes include unit tests for the new capabilities (on the<br> Joomal 3.x version). See the bottom of the this document.</p> <h2>Implementation Notes</h2> <p>The functionality above is implemented by adding functions to JAccess and<br> JRules:</p> <p><strong>JRules::removeActions($action_regexp)</strong></p> <ul class="task-list"> <li>Remove all actions from the rule whose action name matches the regular expression. This a general function and could be used to remove core actions from the root rule, if the calling code requested it (not recommended).</li> </ul><p><strong>JAccess::getGroupId($groupname)</strong></p> <ul class="task-list"> <li><p>Returns a group ID for the given group name.</p></li> <li><p>This could be moved elsewhere, but there did not seem to be a suitable<br> place. We may want to add a JUserGroup class (in<br> libraries/joomla/user/group.php) and move this function into that class.</p></li> </ul><p><strong>JAccess::removeDescendentGroups($groupIds)</strong></p> <ul class="task-list"> <li>Removes all groups in the provided set of groups that have ancestors in the set of groups. This is part of the code that helps select the least authoritative group since it eliminates children of groups that are already in the set since the child group is likely to have more permissions than its parent group.</li> </ul><p><strong>JAccess::leastAuthoritativeGroup($groupIds, $asset)</strong></p> <ul class="task-list"> <li>Selects the least authoritative group out of a set of groups.<br> Read the code for a clearer idea of how this works.</li> </ul><p><strong>JAccess::installComponentDefaultRules($component, $file = null)</strong></p> <ul class="task-list"> <li><p>Parse the rules for custom rules in component's 'access.xml' file and<br> install new permissions in the root asset, as needed.</p></li> <li><p>Does not allow modifying core rules.</p></li> <li><p>If a group with the required permission is not found or the group name<br> specified in the hint part is unknown by the Joomla installation, the<br> default specified will be ignored. Currently a log message is being added.<br> This should probably be a JApplication::enqueueMessage() call but I could<br> not get that to work in the unit tests.</p></li> <li><p>This function can be called any time, but it would make sense to call this<br> during component installation in the postflight section.</p></li> <li><p>The optional $file can be used to specify an alternate location for the<br> 'acess.xml' file (for testing).</p></li> </ul><p><strong>JAccess::purgeComponentDefaultRules($component)</strong></p> <ul class="task-list"> <li><p>Removes all custom rules for $component defined in the root asset.</p></li> <li><p>Core rules will not be modified.</p></li> <li><p>This function can be called at any time, but it would make sense to call<br> this during the uninstallation of a component (during preflight or the<br> uninstall function).</p></li> </ul><h2>Unit tests</h2> <ul class="task-list"> <li><p>Unit tests for Joomla 3 that cover the features above have been added to<br> the <em>tests/unit/suites/libraries/access</em> folder.</p></li> <li><p>The custom unit test configuration file<br><strong>tests/system/servers/configdef.php</strong> was added to the toplevel .gitignore<br> since it could contain private data and should be ignored (like .gitignore<br> already ignores the top-level phpunit config file <strong>phpunit.xml</strong>).</p></li> </ul><p>Jonathan Cameron<br><br> April 28, 2013</p>
Labels Added: ?
avatar brianteeman brianteeman - change - 21 Aug 2014
The description was changed
avatar brianteeman brianteeman - change - 21 Aug 2014
Status New Pending
avatar nicksavov nicksavov - change - 21 Aug 2014
Labels Removed: ?
avatar brianteeman brianteeman - change - 25 Aug 2014
Category ACL
avatar nicksavov
nicksavov - comment - 17 Oct 2014

Hi Jonathan,

Could you close this one and submit it toward the staging branch instead?

avatar jmcameron
jmcameron - comment - 17 Oct 2014

Nick,

I'm not quite sure what to do about this. I agree with Elin's concerns that my approach to handling the permissions depends on a somewhat arbitrary ranking of permissions. However, I do think that the problem of adding default permissions for cusom component ACL rules is a real problem. In developing the Attachments extension, I have good reasons and use cases for the custom ACL rules it provides. Joomla provides no simple mechanism to specify default permissions for these custom ACL rules.

I think my approach is generally good, but I agree that handling the permissions needs to be done more intelligently since the permission hierachy is really very arbitrary in Joomla (although it the basics for com_content are very consistent in most installations unless the developers have done some pretty drastic surgery).

Thank you for your offier to talk with someone at the J3 feature meeting. I would still appreciate it, but I do not intend to resubmit this pull request immediately. If someone else is interested in working on this I'm willing to partner with them and develop a new approach and start a new pull request.

-Jonathan

avatar brianteeman brianteeman - change - 17 Oct 2014
Title
[#30550] Default Component ACL Rules (3.x)
Default Component ACL Rules (3.x)
avatar Hackwar
Hackwar - comment - 17 Nov 2014

I have to agree with Elin here, this does not look like a good idea. You are forcing a bunch of permission names on us, that not everybody is using in their components, as well as ranking groups/permissions, which I think is a very bad approach.

I would ask the maintainers to reject this one.

avatar jmcameron
jmcameron - comment - 17 Nov 2014

I will close the pull request. I am convinced too that this approach relys on typical, but not guaranteed, groups and ACL permissions. But I still feel that we need some way define default permissions for cusom component ACL rules. I am open to ideas on how to address this issue, and perhaps some of the basic ideas in this pull request can be adapted to some future approach.

-Jonathan

avatar jmcameron jmcameron - close - 17 Nov 2014
avatar jmcameron jmcameron - change - 17 Nov 2014
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2014-11-17 01:48:23
avatar jmcameron jmcameron - change - 17 Nov 2014
Title
Default Component ACL Rules (3.x)
[#30550] Default Component ACL Rules (3.x)

Add a Comment

Login with GitHub to post a comment