Role-based access control (ACL) at front end??

[sathyashrayan]

After i went through some explanations on ACL and watch some videos,
this is what i understand with ACL. It is the access privileges for a
set (groups) of users to administrate the backend. Example , a joomla
2.5 site with shopping cart where the site administration is shared
among data entry operators. To achieve this we create a group as "data
entry operators" and give privilege to upload/delete/ product details
and denying them to see customers address. I learned how this could be
created with access.xml and ACL functions in the model.

Let us have an another situation where the front end objects "Obj A"
can be handled (operation like ADD/EDIT/DEL) only by group "A" and
group "B" has been denied either ADD/DEL or EDIT and allowed only to
view. I think this is not possible with existing ACL of joomla
2.5.Correct me if i am wrong..

I went through these link and gurus here could point me out with
bitwise operators to achieve this.

http://en.wikipedia.org/wiki/RBAC
http://jmcneese.wordpress.com/2009/04/19/rmac-ftw-part-1/

[Mark Dexter]

You can have as many groups as you need, and each group can have entirely different permissions. So I don't see any problem with doing what you need.Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[elin]

ACL is in operation in both the front and back end. You can see that by the way that create, editing and edit state privileges work in the core weblinks and articles components. There are extensions that use eve core.admin in the front end, that is one reason that the string for that permission was changed (because administration does not necessarily happen in the administrator for example forum admins often work in the front end of a site. A  Joomla application is a Joomla application.

Elin

[sathyashrayan]

Thanks for the reply Mark and Elin..
I did the following to understand more on this ACL.
1)Created a new group called "web link group root" under that i have
two sub groups "can not see" and "can see"..
2)Created two users user-1 and user-2. user-1 will be under the groups
"Registered" and "can not see". user-2 has "Registered","can see"..
3)Went to components->weblinks->options->web link group root i select
allowed in all except "Configure", "Access Administration Interface"
4)Then i click "can not see" and select "Configure" and "Access
Administration Interface" to "inherited" and other options as
"denied"..
5)Then i click "can see" and select all to "inherited"..
6)Created a new menu that points to weblinks =>Submit a Web Link view
(form).
7)When the user-1 logs in he can not see the web link form. But user-2
logs in could see the form.

I opened the access.xml in administration/components/com_weblinks i
could see the set of access permissions. These permission is getting
listed in the step-3 to 5 of above. In the file site/components/
com_weblinks/controllers/weblinks.php i could see these functions
1)allowAdd() 2)allowEdit() that calls the JUser->authorise() which is
the main reasion for the denying of user-2 and permitting user-2 of
the above step-1 to 7.

As a next procedures i download the component developing tutorial's
hello world for 1.7 from http://docs.joomla.org/Developing_a_Model-View-Controller_(MVC)_Component_for_Joomla!2.5
(http://www.glennarkell.com/joomlaorg/com_helloworld_0.0.18.zip)
installed it and opened the access.xml in the administration/
components/com_helloworld/access.xml I add the following new line
(rule)

<action name="core.test" title="test ignore" description="test by ACL
learner" />

Now i open the administration->component->com_helloworld->permission i
could see my new test permission in the list. I belive that this is
the way i could provide my own custom permission for both frontend and
backend. But i really don't know how..!! Where is the documentation or
examples for that? If a case study then that would be very fine.

Off topic..
I have started to learn joomla along with 4 of my friends. All the
other 3 friends changed their learning in drupal. Their say is.. "we
are finding a good documentation and examples with drupal compared
with joomla". I stand out of words..

[elin]

Seeing the weblinks submission form would be dependent on the CREATE permission. Seeing the icon to edit an weblink and getiing access to a form with data would be the EDIT permission. The configure permission would have nothing to do with this nor would the access administrator interface permission.

The Administrator interface permission is just that, accessing the interface for administering weblinks. This is only found in the site administrator. Some extensions, such as Kunena, do have such an interface in the front end and in that case that permission would come into play.

Yes you are correct that just adding a new line to access.xml is the way to add a new permission. Then  you would just use that in the same way as you would for using the standard permissions.

Elin

[Beat]

elin <elin.war...@gmail.com> wrote:

> Yes you are correct that just adding a new line to access.xml is the way to
> add a new permission. Then  you would just use that in the same way as you
> would for using the standard permissions.

access.xml is great, but I have not found a way of defining default
group permissions.

The system default for any new permission is unfortunately DENY for
all groups.
In Joomla core, for the default groups, it's defined in the pre-
populated assets table.
But as there are no core-level group permissions for "custom" new
permissions, they default to undefined, which displays as DENIED in
the permissions config manager.

Which means that adding such a new permission will make the function
not usable until the admin finds his way into the Config/Permissions
settings and understands how Joomla ACL works. Which means it's not
usable for 99% of the users unfortunately.

Thus: Is there a way, e.g. in the XML file to specify a default value
for the standard Joomla groups ?

Can someone please clarify what is the best and clean way to define
default permissions for new permissions (without "hacking" the assets
table...).

Many Thanks,
Beat

[elin]

 I think it's a good, security conscious  fall back assumption that in the absence of other information a user does not have permission to do the specific action. The converse is rather scary if you think about it. 

Why is it that you you can't do something similar to what com_config does but in a post flight script?

https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_config/models/component.php#L109

The challenge of course is that you don't know what groups exist besides public and super admin and even with them you don't know what name or number they are using. So you would have to look at the user group table and find all of the groups with parent=1 (public) i suppose. 

Elin

[Beat]

Yes, a *default* fall-back to Denied is good.

However for *new* permissions, being able to set *new* defaults for
the default joomla groups is really needed.

When using access.xml and config.xml using the standard "Options"
toolbar button for your component, which uses com_config in a modal
iframe, there is no way to do your own pre or post flight.

Or did you mean at component installation time to add defaults in the
assets table if none is defined for the new permissions ?
If that's the case, I was wondering if there is a more elegant way,
e.g. if the Joomla installer or com_config could read those defaults
off an xml file (e.g. in access.xml) and add those default new assets
permissions at install/upgrade time if they are not existing ?

Best Regards,
Beat

On Feb 19, 1:30 am, elin <elin.war...@gmail.com> wrote:
>  I think it's a good, security conscious  fall back assumption that in the
> absence of other information a user does not have permission to do the
> specific action. The converse is rather scary if you think about it.
>
> Why is it that you you can't do something similar to what com_config does
> but in a post flight script?
>

> https://github.com/joomla/joomla-cms/blob/master/administrator/compon...

[elin]

Yes I mean post flight at installation/upgraade since that is already built into the installer and that is where it would make sense to set the defaults.

It's really just a matter of someone writing the code to implement and engaging in the discussion of the right way to do so etc. This is something a number of people have requested in the CMS.

As i said, the tricky (but not too tricky) part is getting the appropriate list of user groups since you would not want to make the assumption that the default ones are present or if present mean the same thing that they mean in a default install and also that there are not other groups that need to be configured. Because of that I think it would be not simple to read from an xml file without doing some further processing.  But the API makes it easy to get the array of user groups and the tree structure, it would just be a matter of you writing it and inviting people to test it unded various scenarios. 

Elin