[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DB Changes




Huh?  Maybe I'm dense (been accused of that a few times) but what is the
purpose of multiple values for the "RoleID/Location".  I don't get it.
What does this do for us and why should we care?  How is the
Apache::AuthenDBI module supposed to evaluate each value? 

-Aaron

On Sun, 18 Jul 1999, Jason Pincin wrote:

> Well - 
> 
> The new DB structure has been in place for a few days now.  I'm feverishly
> working on fixing things I've broken.  And I'm anxiously awaiting the
> questions from this list that I've anticipated.  So please - nail me with
> them :)
> 
> Aaron & Micah:
> 
> There is another minimal change I want to make.  Don't yell at me.  Just
> listen a second :)
> 
> It does affect the two of you in a very minor way.  It related to RoleID
> in the Users table.  Instead of Micah dumping in a default value of 1 or
> whatever into that during user Signup, I want to change that field name to
> "Location", and just have Micah dump a default location value into it
> instead.  The permissions in the DB will then be assigned to the location
> of the user in the tree.  This has no impact on ANYTHIN developed thus far
> except for the name of the field, and what value Micah submits.  Should
> only take a few seconds for him to change.
> 
> It also affects your ModPerl security design Aaron.  But not too much.
> Instead of looking for a value of 1 in a field named RoleID - you'll be
> looking for a value such as "2.20" in a field called "Location".  
> 
> As you can see - it's prolly a few minutes worth of changes across
> everyone's time.  But, as a result - users are completely integrated to
> the object tree in the backend DB, and security would be able to be much
> more flexible.  It replaces Roles with Groups.  
> 
> Permissions on a user could still be looked up in a single one table query
> this way.  To look all permissions assigned to a user, you simply:
> 
> select * from Permissions where ObjectID = 2 or ObjectID = 20
> 
> The where clause is generated dynamicly by split() 'ing the location
> string of the user based on ".".  Another example:
> 
> User has location "2.20.97"
> 
> 2 = Root os user tree.  20 = A group.  97 = the object representing the
> user in the tree.  By performing the query above where OID = 2 or OID = 20
> or OID = 97 you get the permissions assigned to the user, the group he
> belongs to, and all users (if we do such a thing).  Permissions by
> inheritence.  It's a beutiful thing.
> 
> I know we're concentrating on go-live.  And I don't want to change the
> backend unless needed.  But this change should only require a few minutes
> of time on the part of Aaron and Micah.  And a few minutes on my part.
> Lets go ahead and do this.
> 
> Jason
> 

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.