[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DB Changes
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.