Re: [rfc] permissions managment

<rashid@ds.pg.gda.pl> wrote : > i think its the time to think about perms class(es). i exchanged some emails > with martin jensen about it. we agreed that there is a need for such > functionality. during the discussion we came to something like this: > - new category (probably Perm) or subcategory in Auth > - rather few classes than one > > why multiple classes? there are two basic categories of perms system needed: > for basic use and for advanced use. the first one is when you need something > more than Auth class but not to complicated. my idea is (as shown earlier > here) simple binary encoded perms value, ie. > perms['Student'] = 1; > perms['Moderator'] = 2; > perms['Administrator'] = 4; > ... > (this array would be only needed for displaying permissions desription) > > in a container there would be one more field needed for storing perms (ie.. > moderator + administrator = 2 | 4). i think you all get the idea - its > simplest perms system possible imho. it is ready - it required few changes > in auth class and in container (currently db container works, i haven`t > tried it with the other ones). > > this is enough for 99% of website`s, but probably not enough for over 50% of > enterprise class applications. so - this is why second class is needed. i > received a short description of something like this from tim gallagher (i > might be wrong, but hopefuly it was him :)) - a perms managment system that > requires a website to be fully used. i didn`t quite get all the ideas > standing behind it so i think it would be best for us if tim had shown us > the description to discuss it. i`m not sure that the idea can be realized > extending Auth class, but it shouldn`t be a problem - the class could do on > its own. > > the discussion we should have here is: > - to do or not to do? > - where to place this in pear structure? > - who is going to make it? :) > - everything more you think should be discussed here > > rashid > perms['Student'] = 1; > perms['Moderator'] = 2; > perms['Administrator'] = 4; The basic perm system you suggest already exists in PHPLib and works very well for basic permission checking. Its advantage is that it is quite flexible and can be used in many cases. But it requires a good planning beforehand. Nevertheless, there have already been some discussions about a more advanced system. These messages could give you an idea. I find the one of Kristian Koehntopp particularly interesting : http://marc.theaimsgroup.com/?l=phplib&m=96335538430169&w=2 http://marc.theaimsgroup.com/?l=phplib&m=98482830224825&w=2 > - to do or not to do? It is definitely needed, just like a user class is a must-have. My opinion is that Auth/Perm/User should work together, will they be basic or advanced.. > - where to place this in pear structure? First, I think the Auth class should be renamed to something more specific. I don't see why there should be only one auth package in PEAR. So, keep the Auth category and call the class Auth_Simple or something. Then in Auth, make a subdirectory called Simple with containers and so on, just like the way it is in the HTML category. Auth |__ Simple.php |__ Simple |__ Container.php |__ Containers |__ DB.php |__ File.php |__ ... It's up to you then to choose if your Perm class will be useable by other Auth classes or only by the simple one. It will depends on its design. If it is only for Simple_Auth, create a new directory in Simple directory called Perm, then Basic or Advanced depending on the class features. On the other, if its design is compatible with other Auth classes, create a new category called Perm and put it in there. That's just an idea. IMO it would make PEAR more extensible than it is now. Bertrand Mansion Mamasam