Re: DB Changes

[Jason Pincin <jpincin@ashtech.net>]

Well, once renamed to location it will contain the users location in the
object tree.  This allows greater flexibility in permissions.  I can
expound upon that if need be, but trust me.  From the DB side... it's much
greater flexibility in permissions.

One example is the ability to nest groups of users.  A user could be 3
groups deep, and inherit the permissions of all 3 groups above himself.
Thats just a quick example - we can talk about it more if you like, but it
will take far longer to talk about it than to actually do it :)

Apache::AuthenDBI won't evaluate each value.  It will simply evaluate the
value of location as one string, just as it is doing now for RoleID.

Jason


On Sun, Jul 18, 1999 at 03:42:16PM -0700, Aaron Turner wrote:
> 
> 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.