[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DB Changes
Must the "group" be an integer, or can it be a tring comparison?
Jason
On Sun, Jul 18, 1999 at 09:59:43PM -0700, Aaron Turner wrote:
>
> After thinking more and more about this, I'm less and less certain that
> it's worth it. Maybe its because I don't understand the value. I mean,
> just how many groups do we need? If it's not more than 10, there's no
> point IMHO. Also I still don't know how we're supposed to evaluate the
> strings.
>
> Let's say Joe has a "location" of 1.3.10, and he's trying to go into a
> directory with a value of "1.3.9" does he get in? "1.3"? "1.3.10.15"?
> Is this "location" thingy supposed to equate to "o"? If so, why can't we
> have a table that relates o to location and use the recordID as the
> RoleID? I know it's an additional query, but it should be super-fast
> since you're looking up based on the index.
>
> Anyways, as a little refresher, let me remind everyone how the AuthzDBI
> module works.
>
> Basically you have a .htaccess file that tells Apache:
> the DB & server
> the table in the DB to find the username/group
> the field for the username in the table
> the field for the "group" in the table
> a list of valid "groups"
>
> So, after a person does a http-authentication (via AuthenDBI) Apache does
> an authorization check. It grabs the username from the
> http-authentication headers, and uses that username to do a lookup against
> the table specified. It then tries to do a match of the group specified
> for the user in the table vs. the list of valid groups in the .htaccess
> file.
>
> So, ignore when I said that AuthenDBI evaluates the RoleID as a integer, I
> lied.
>
> Anyways, right now I'm quite a bit confused. I don't know if your new
> method requires any modifications to the AuthenDBI module. If it doesn't
> then, do what you like. If it does require changes, let's talk more.
>
> On Sun, 18 Jul 1999, Jason Pincin wrote:
>
> > 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.
> >
>
> --
> Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization http://linuxkb.org/
> Because world domination requires quality open documentation.