Re: PEAR::LiveUser authentification/authorization

On 5.4.2006 12:38 Uhr, qMax wrote:
> 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.

Which would be the auth module then. We have a perm and an auth module, 
they both or somehow independent of each other

> 
> 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.

Again, where you store that, it's the task of the auth module. If it 
makes sense to store it in a session, fine :)


> 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

I'm not really sure, if you can break it down to that. Sounds very 
interesting and a nice solution, but if you have for example 2 different 
plugins at one URL and want to have different permissions for the two 
plugins, you can't do that as they have the same URL.

> 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.

yep, IMHO, that is needed. Otherwise it's not as finegrained as it could 
be. And for example for the navigation you need to do that in the plugin 
anyway.

> On the other hand - while having uri-based acls, permissions can be checked in pipeline,
> w/out calling plugins...
> 
> What d'yu think ?...

I'm not sold to the idea, yet .)

chregu



-- 
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [email protected] |  GPG 0x5CE1DECB
-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms