Re: PEAR::LiveUser authentification/authorization

On 5.4.2006 7:22 Uhr, qMax wrote:
> Tuesday, April 4, 2006, 7:21:41 PM, Christian Stocker wrote:
> CS> It's called *simple*perm for a reason :)
> CS> The main idea behind the permission framework was, that the perm modules
> CS> are exchangeable, depending on what you need. simpleperm was just a 
> CS> quick solution for this. a more advanced perm is on our TODO list, but
> CS> still it will just be another permmodule. The main advantage is, that 
> CS> simpleperm is fast and is enough for a lot of use-cases.
> 
>>> The closest framework i've found to satisfy these needs is PEAR::LiveUser.
> CS> Yes, but it's a beast :)

> I'm very lazy to implement something own.
> I'm not programmer at all...
> LiveUser can work in 3 configurations of various beastness.
> "simple" is just as you have and "middle" is what i need.

Then off you go :)


> CS> referer? OMG :) I agree with the rest, but that should be handled in the
> CS> isAllowed method of your perm module and not somewhere in the core.
> I just imagineded various possible solutions :)
> Some sites use referer to do not show pictures on foreign pages. Kinda copyrighting.

Sure, but you do that better with .htaccess and mod_rewrite. But that's 
not the point here :)

> Yet another curious example i thought for intranet - netbios lookup for logged in user
> on client ip, this way users should not log on site separately.

agreed

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

But it's still the job of the perm module and not sth for the "core"

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

Sorry, I think I mixed something up :)

There are "roles" and "actions" IMHO. "roles" are more like groups and 
"actions" are what you can do. But that's just my terminology (which i 
used wrong in the last mail)

So, there are actions like "blog_post" and "blog_comment" for plugin 
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.

yep, there should also be some of the more generic actions like "create" 
etc..

Example. Creating new blogposts would be checked with

->isAllowed(array("create","blog_post"))

which means that I either need to be allowed to "create" sth (on that 
URL) or to "blog_post" (on that URL). This way, I can give people the 
"create" action and they can create sth with every plugin, but I can 
also only give the "blog_post" right, if I want that they just can do 
blog-posts.

The same for example, if I want do only allow some people to use BXE, 
but not the oneform editor

For BXE, that would be

->isAllowed(array("edit","edit_bxe"))

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

This whole thing allows some finegrained and hierarchical rights 
management, IMHO.

chregu

> But then URI space should be designed more carefully...
> 
> CS> If you have any good suggestions for that, we're more than happy
> CS> to hear about it.
> Still no ideas, but certainly i'll have some implementation.
> 
> Maybe it makes sence to use plugin-specific resource-id when assigning
> ACLs, instead of site URLs ?
> (i still can't cleanly get an idea of resource-id, since it used differently
> in various parts)



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