Null SQL user

[Michael Griego]

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  
> how
> 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  
more consistently.

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...

Thoughts?

--Mike