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-tp25183869p25208620.html
Sent from the Zend Framework mailing list archive at Nabble.com.
