About privileges, all depends how you're going to code it I guess.
Concretely (for the "access rights") I have my controllers as resources and
actions as privileges.
My controller names are litteraly stored in my DB, however I am conscious
that the Model shouldn't know about the Controller or the View. So that's
what you're trying to achieve, I suggest you to read that article:
http://www.aviblock.com/blog/2009/03/19/acl-in-zend-framework/
Note that he doesn't mention privileges when he's showing the snippet of
code to suggest.
As in my case, it allows simply to do something like:
$resource = $request->getControllerName();
$privilege = $this->getPrivilege($request->getActionName());
$role = Zend_Auth::getInstance()->getIdentity()->username;
$acl->isAllowed($role, $resource, $privilege)
However I realize right now that I'll need a supplementary ACL object for
the "edition accesses". Some users may have access only to some limited
parts of the site and this cannot be conveyed by controller names. Then I'll
need a third one for the other modules (public site) as those will be
implemented as the customer wants it, which again, may not be based on
controller names.
O gosh ..
By doing it abstract you won't encoutner those problems, but I guess it will
be more fastidious to code it.
netlynx wrote:
>
>
> debussy007 wrote:
>>
>> 1. Where are the privileges ?
>> It seems that often in a CMS there are privileges, e.g. a user may be
>> able to "view" the list of pages but not to "update" them. Some may
>> "publish" or "delete" them, etc.
>> Of course you can keep it simple but keep this into mind if you have to
>> implement it some day.
>>
>
> Ahh, I see what you are saying, I was making the assumption in my logic
> that a role would carry certain privileges. In this respect, an author
> say would have the privilege of creating a document/article, and editing
> their 'own' document. An editor would have rights to create and edit any
> document. A publisher would have rights to publish, but not edit
> documents. So in answer to your question, I was just assuming the
> privileges based on their role, however, I should not have assumed that, I
> will consider that in my schema.
>
>
> debussy007 wrote:
>>
>> 2. Groups <-> Roles
>> I see that you have a "many to many" connection between your groups and
>> roles. Why don't you simply make of a group a role, and delete the
>> UserRole, GroupRole and Roles table ? To affect roles to a user you would
>> simply affect them to one or more groups which each may inherit of other
>> groups. In my case I have a hierarchy in Groups table.
>> If the user is not inside a group, he has access to nothing.
>> Of course you'll have to add a table between your roles and your
>> resources.
>>
>
> I was trying to figure that out too, my logic on this point was a group,
> could have 1 or more roles assigned to it (ie. group:
> {category}_forum_moderators, could post messages (role:author), and
> accept/reject others messages (role: moderator)) and a role could be
> assigned to multiple groups (ie. group: {category}_forum_moderators (role:
> author), and {category}_forum_members {role: author}). Looking at it from
> that perspective, I suppose it could be viewed your way too, by making a
> user part of the {category}_forum_moderator *and* the
> {category}_forum_member groups, thus also giving them the same rights. My
> main thoughts behind this is essentially to make this as flexible as
> possible. If you look at an operating system privileges structure, you
> basically have user/group/everyone -- read/write/execute privileges
> (windows of course breaks this down a little further but essentially the
> same idea). A CMS would incorporate a slightly more granular set of rules
> (overall read/create/delete/modify), but in the case of say a publisher
> having rights to publish a document, well, that is 'modify' rights, but
> only allows them to modify the published field of a document, not 'modify'
> rights to modify the contents of the document. So I think I still like
> the group concept, and the roles would define the granular access of the
> group and/or the user.
>
>
> debussy007 wrote:
>>
>> 3. Content rights
>> I have supplementary tables to handle the access on specific parts/pages
>> of the site. Each group of user may have access on specific category's of
>> the site.
>> So I distinguish two kind of groups: "access groups" which restrict the
>> access on the cms admin interface (menu manager, layout manager, images
>> library, etc.) with the "content groups" (restrict the access to some
>> part of the site). Don't know what you think about this, tell me )
>>
>
> I think that goes back to part 2. I see what you are saying, and I think
> in my layout, I am just defining both types of groups under one category.
> From a security standpoint, I am actually considering moving the admin
> stuff to a completely different server, possibly a different
> domain/subdomain (though thats just a side thought right now). *However*
> limited administrative tasks specifically related to things that users
> (category administration) purging forums, creating sub-categories,
> publishing documents, (just trying to come up with member type
> administrative tasks here), or even category/section specific reporting,
> could be put in a limited administrative screen. So as far as the
> supplementary tables, I am still thinking along the 'groups' umbrella, and
> creating groups for different sections/areas/categories, etc.
>
>
> debussy007 wrote:
>>
>> 4. I have a table per type of user. Admin table for admin cms users,
>> Members table for subscribers, etc. I see that you handle this with a
>> profile table. Not sure which is best.
>> I just like to separate distinct things.
>>
>
> See, that I would find harder to manage. To me, a user is a user is a
> user. (At the lowest level, a user could be merely a guest /
> non-authenticated user, but they still have rights (view the homepage at
> least), at the highest level they could be the implementor, having
> absolute power over every aspect of the site, of course then there is
> everyone in-between). So I am not exactly sure how having 2 separate
> tables is a benefit, as that would mean extra queries for authentication
> at very least. Unless of course your admin/backend *ONLY* queries the
> admin table, and the other areas of the site *ONLY* query the members
> table), but even at that, there is bound to be some 'component' that only
> an admin is going to have rights to that resides in the public / frontend
> portion of the cms, and thus, you will have to query both tables anyhow.
>
> Now I mentioned in the original post that the user table would also have
> any 'fields' that are site-required, (which most likely would include
> e-mail, and I realize I put e-mail in the profile). My concept actually
> on this (slight revision), is that a profile would actually be a piece of
> content, and doesn't really belong in this structure at all. Really a
> profile (in what I am trying to accomplish), is just another document
> type, just like an article, or forum post, or what not. The contents of
> the profile really should be definable at an administrative level of
> course, but not set in stone hard coded. For example (and this goes to a
> multi-site, single application concept), for example a category based
> division of the site. (follow me on this)
>
> blackjack.example.com -> user -> profile -> blackjack related information
> (favorite online casino)
> holdem.example.com -> user -> profile -> poker related information
> (tournament rankings)
>
> Now also this would have the same kind of document rules as any other
> document, user would have rights to edit it, and user would be able to
> define who had viewing rights to the information (maybe he wants to only
> allow his friends (oh yet another group :) ) allowed to view it. So now
> comes the other side, a resource such as a category would contain zero or
> one profile document types per user.
>
> Yes I have heard of the 'K-I-S-S' logic, and I completely agree (in some
> respects), I am trying to come up with a system that is very flexible (a
> framework per se, for my own projects, but maybe one that someone else
> could find benefit too), hence why I want to make the Acl as robust as
> possible and why it is somewhat more complex than the average user has
> such and such rights. It is more of an ORM for Acl.
>
> Obviously there are 100 different ways to accomplish the same (or similar
> task). Thats why I am looking for as much input as possible to create an
> extremely versitile Acl structure. Thank you for your insights, would
> love to hear your thoughts on my responses/views.
>
> Thanks
> Aaron
>
--
View this message in context:
http://www.nabble.com/Complex-ACL-tp25183869p25220538.html
Sent from the Zend Framework mailing list archive at Nabble.com.
