Re: [phplib] Re: [Phplib-users] preexisting perm integration

[giancarlo p. <gia...@na...>]

giancarlo pinerolo wrote:

> 
> Michael Bonfert wrote:
> >
> > Hi,
> >
> > apart from the auth and user problem we have to keep in mind that there
> > are different approaches to perm.
> > At present phplib has a level-based perm policy. Think about an object
> > based perm policy.
> >
> > e.g. a discussion board software with different boards. You have at least
> > 2 objecttypes board and boardmessages.
> > The boardmessages live in the context of their board. You have different
> > priv's on these objects. e.g.
> >     bboard_create_forum
> >     bboard_create_message
> >     bboard_write_forum
> >     bboard_write_message
> >     bboard_read_forum
> >     bboard_read_message
> >     bboard_delete_forum
> >     bboard_delete_message
> >     bboard_moderate_forum


I think that a 'privilege scheme on objects' presumes two things:

You have objects and groups of objects. Each object (or group of)
requires certain priv. So to each obj are associated a series of
'required privs'

Then you have users and groups of users. Each user or group has (can
prove to have) certain privs.

When you check the permission, you compare the list of 'required' privs
one one side, with the list of provided permissions by the user. And
this can risult in a third lst, which is what you can do on there.

Phplib can hold the permission/privs associated to the users. I am not
sure it will provide holding perms requirements for objects. It can hold
the third list above for each user, the result of the comparison between
an object's requirement list , ant that user provided permissions. In
practice which objects, after having compared the two, he can access.


And you can use phplib to get or set the permissions the user  will be
able to present to a requiring object.

You can write routines like

show_login_form_if_perms_are_NO_OK($userperms,$objperms)

but of course you have to write that.


Ant then objects as well belong to gropus, an probably the comparison
betwwen the twoo lists can be made on group belonging on both sides...

Gian

> >
> > Assume you have different boards (board1 and board2).
> >
> ...
> 
> Well, this is all very application specific. An authentication
> service/scheme whatever, can tell you or confirm you the identity, the
> group belonging, and give you a list of perms associated.  By perms I
> mean the 'names' of these perms. Nothing more. It can give you a method
> to check if 'a name of a certain perm' is associated with the user. It
> has not to take any further action though. That's the application realm.
> The fact that phplib somehow automatically handled out login forms is
> misleading.
> 
> And then consider that these 'perms on objects' are very fluid: for
> example I can have a perm on playing 'gameB' if I obtained as much
> scores to 'gameA'... The presence of any single checkbox can depend on a
> certain perm.. How can nphplib manage the 'enforcment' of that? The
> application is provided with a persistent per_user storage, you can keep
> there a list of the actual, live, user perms, or store an object of
> yours  that  hands these out... I mean, every condition, every 'if'
> statement,  is sortof a perm...
> 
> Giancarlo
> 
> > board1 ist moderated by user1, every user can read,create,write a message
> > but only the owner and moderator can delete a message.
> > user1 gets all priv. above on board1. Alle msgs of board1 live in the
> > context of board1 so these objects inherit the privs of board1 => the
> > moderator is able to delete all msgs of board1.
> > Other user have the common privs
> > bboard_read_forum,bboard_read_message,bboard_write_message.
> > 'bboard_delete_message' is assigned only to their own msgs.
> >
> > board2 is moderated by user2 ...
> >
> > This example shows that  permission is a little bit more complex than
> > level based.
> > 'Can this party perform this operation on this target'.
> >
> > There could also be other approaches to perm.
> > I think phplib should be open to integrate 'preexisting perms',  too.
> >
> > bye Michael
> >