Re: [rfc] permissions managment

From: Date: Tue, 13 Aug 2002 14:01:34 +0000
Subject: Re: [rfc] permissions managment
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-8365@lists.php.net to get a copy of this message
I've tried to send this to the list before, but my mail server must be blackholed. I admin my server, and have gone to a lot of trouble to get it unlisted before, and to my knowledge it isn't open, so I don't have any idea why my messages to the list bounce. anyway... I'll resend my email to you and you can forward it to the list. maybe i'll send it from my yahoo account also. yes, that's what i'll do. original email: ----------------- I don't know if what i'm about to describe will fit auth, but after looking over the docs, and the code for auth, I believe it wouldn't be too difficult to implement. if it's possible to extend the auth class to provide either an additional table, or additional fields (which would involve extending the container classes) I have a system working that allows for a chain of inheritance from one user to another. a user record has a groupID, or a group table could be created CREATE TABLE group ( username varchar(255), groupUsername varchar(255) ) using a separate table for user group associations would allow a user to belong to more than one group. Or, as another option, the permission system could restrict group entries to only one per username thus making permission inheritance a reality. The last is the way I prefer to work. precedence of permissions would need to be addressed for users who belong to more than one group. precedence of permissions is taken care of automatically by the permission system for the inheritance method of permissions. Given a chain of groups, starting at the user, and working further away, work in reverse order to establish permission. in other words, if you have a username "tim" and in group you have an entry for username=tim groupUsername=admin another entry for username=admin groupUsername=standarduser and another entry for username=standarduser groupUsername=basicuser the permissions are loaded in this order, newer values overwriting earlier values. basicuser standarduser admin tim so if you had a permission entry for tim that says "SystemAdmin::Edit Files" and Allow_Deny="A" even if basicuser denied that permission it would still be allowed because tim's permissions are the last to be loaded. given a database for permissions CREATE TABLE items ( Item_Name varchar(255), PRIMARY KEY (Item_Name) ) CREATE TABLE userperms ( username varchar(255), Item varchar(255), Allow_Deny char(1) ) In a permission class, I have the following methods: check _register _isRegistered check tries to register the item if it's not. this allows an easy to use "registry" of items for use in an admin screen that would set the allow or deny flag for a particular user. a user interface i've created for just such a system is shown here: http://www.smur.net/images/screen1.png this was rendered in netscape 6.2. the inherit button simply deletes any permission setting for this user thus letting the previous group setting come through in the permission loading process. the set for this user button takes the permission specified, checks to see if it exists for the user, if not it adds one, if it does, it updates the existing record. the move buttons move permissions from one list to another. if a permission is inherited and moved, it belongs to the user being edited. well... this is my two cents worth... i don't know if this is the direction you're wanting to head in, but this type of system is serving me quite well for a complex intranet site i'm developing. -timmyg timg@sunflowerroad.com ...
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


« previous php.pear.dev (#8365) next »