Re[2]: PEAR::LiveUser authentification/authorization

Wednesday, April 5, 2006, 4:09:41 PM, Christian Stocker wrote:
>> CS> Basically, if you don't need permissions, it shouldn't slow down Flux
>> CS> CMS. Maybe some more isAllowed calls, but the "true" perm-module just 
>> CS> returns true there. always.
>> When using groups, isAllowed should lookup group membership from
>> database on each request and should cache it by itself.

CS> But it's still the job of the perm module and not sth for the "core"
Hm...
I think, the knowledge of user database is better to be incapsulated in single
module.

I'm seing situation this way:
It is an auth module, who authenticate users in this database,
And it is the same database, where u get another user properties,
like groups.
Then, at once, it can set up all credentials for user -
a groups user belong to, ip ranges from the same database, etc.
All credentials could be stored in session so rest of system could use
it w/out knowledge of where they were burn, and w/out interfacing with users
database.

Perm module job is just check if an action/role for given uri can be
provided to user, usgin the user properties, already determined on
authentication stage.
When perm module is to check groups - it has to deal with 2 unrelated
databases.

>>>> And also there's a question:
>>>> How could i configure custom roles,
>>>> for instance - 'post' and 'comment' for blog
>>>> (supposed to be in user-space, not an admin interface)
>> 
>> CS> we need  some common "ground" for the roles in the isAllowed calls, 
>> CS> currerntly we only have "admin", "read" and "read_navi" there.
>> The permmodule interface does not restrict what 'action' parameter is.
>> The question is how and where to setup the roles.
>> CS> We certainly need more (and they have to be integrated into the
>> CS> plugins/etc) for more advanced perm-modules.
>> CS> But all should use the same roles.

>> Do you mean that roles should be shared betwean all plugins and should
>> not use it's own ?

CS> Sorry, I think I mixed something up :)
But resulting idea became very meaningfull...

CS> There are "roles" and "actions" IMHO. "roles" are more like groups and
CS> "actions" are what you can do. But that's just my terminology (which i
CS> used wrong in the last mail)
It seems like different auth/perm frameworks use this term differently.
Common sense, i guess is: "role" is a group of users allowed to do something on specific URI.
It may be implemented both as groups or as some ACLs.

I very like idea, when premissions/ACLs are just assigned to URIs.
While website is RESTfull application, everything could be identified with URIs.
This could simplify life alot.
But, for some cases, i guess there will be needed URI templates...
This doesn't seems like big problem.

CS> So, there are actions like "blog_post" and "blog_comment" for plugin 
CS> generic actions, so plugins don't really have to share the same "roles"
>> Then 'post' and 'comment' roles should be interpreted to something more common
>> like 'create' for more specific URIs...
>> Hmm... this realy makes a sence, since all operations on site fit in
>> CRUD scheme, +maybe 'admin' role as special case.
CS> yep, there should also be some of the more generic actions like "create"
CS> etc..
And again, in general, only 4 actions needed: create(post), request(get), update(put), delete.
If to use URI to identify resources and actions properly,
this could simplify life alot more.

CS> Example. Creating new blogposts would be checked with -
CS> isAllowed(array("create","blog_post"))
CS> which means that I either need to be allowed to "create" sth (on that
CS> URL) or to "blog_post" (on that URL). This way, I can give people the 
CS> "create" action and they can create sth with every plugin, but I can 
CS> also only give the "blog_post" right, if I want that they just can do 
CS> blog-posts.
I guess that 'create' on blog collection is functionally equivalent to
'post', and 'create' on particular post could be equivalent to
'comment':
ACL{'/blog/', {read,create}} - allow to read and post to blog
ACL{'/blog/cat1', {read,create}} - allow to read and post to blog category cat1
ACL{'/blog/archive/????/??/??/*.html' {create}} - allow to create comments for all posts

CS> The same for example, if I want do only allow some people to use BXE, 
CS> but not the oneform editor
CS> For BXE, that would be
->>isAllowed(array("edit","edit_bxe"))
ACL{'*?editor=*',''} - deny every editing
ACL{'*?editor=kupu','get'} - allow editing with kupu
(longest matched pattern has hogher priority)

CS> and then I can only edit, if I either have the "edit" or the "edit_bxe"
CS> action.

CS> This whole thing allows some finegrained and hierarchical rights 
CS> management, IMHO.
I just dislike assigning permitions for plugin actions.
This will require the plugins themselves to check permissions.
On the other hand - while having uri-based acls, permissions can be checked in pipeline,
w/out calling plugins...

What d'yu think ?...

-- 
 qMax

-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms