Null SQL user
mgriego at utdallas.edu
Fri Sep 22 15:55:41 CEST 2006
On Sep 22, 2006, at 7:08 AM, Peter Nixon wrote:
> It seems to me that while this is "close" to the users file
> behaviour it is
> NOT the same. If its not the same then I'm not sure that it matters
> different it is. Maybe we should add an extra query for a DEFAULT
> user which
> always runs before the standard queries? This would be much closer
> than what
> you are suggesting (I think)
Well, I do disagree with which is more close to users file
processing, however the way you're doing it does add a bit more
flexibility in the request handling, so (like I said in the
beginning), I'm not against it, just want to make sure things operate
In any case, I do have a different idea I came up with this morning.
It involves consolidating the radcheck/radgroupcheck and radreply/
radgroupreply tables into just radcheck and radreply. Basically,
what would change is, instead of having a "UserName" or "GroupName"
column, you'd have one table with a "SectionName" column. This would
be roughly equivalent to the groupname as it sits now (or, rather,
descriptive names for sections of the users file in SQL). When
processing occurs, the entire existing mechanism for radcheck/
radreply is no longer used (skipped). Instead it goes straight to
group/section processing, and users are only members of sections.
Yes, it means you will have more groups/sections in your database
tables, however it has several advantages:
1. All check AVPs are in one table and all reply AVPs are in one
table (less places to look to see what attributes will apply to a
user, and less unnecessary tables)
2. This *most* closely matches the way the users file is processed, IMO
3. It *greatly* simplifies the code in the sql module
4. Less queries to muck with
And, you can even keep things the way you want them now where a zero-
length username is a valid entry separate from the DEFAULT sections.
I know this is something of a major shift in the way the sql module
processes authorizations, but I think it would be a worthwhile
change, maybe for 2.0...
More information about the Freeradius-Devel