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

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.

>> It seems like not much modifications should happen in core.
>> (beside writing LiveUser backends/wrappers for bxcms)
CS> You just have to write a new permission and evt. auth module. Basically
CS> there's no need to change something in the core (more about that below)
Yep, i see now...

>> /*
>> although,
>> it is possible to refactor auth and perm interfaces to better support
>> random credentials (user,group,ip-range,or ever referer)
>> */
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.
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.

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.

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

-- 
 qMax

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