Null SQL user

[Peter Nixon]

Hi Mike

How/Where is this DEFAULT user checked in SQL? I was of the impression that 
DEFAULT data didnt work in SQL. (It it does I obviously am missing 
something.)

In anycase, we are calling a stored procedure for authorize instead of the 
default query
* based on certain (trusted) info in the auth request we already know "who" 
the user is.
* we do a bunch of checks to see if their acocunt is active ELSE reject
* we check the users type. Types include noauth, auth and proxy.
* If proxy type we proxy them to a realm
* if auth type we return the password ELSE accept

A similar procedure runs for the reply query...

As you can see a request with NULL username is quite valid for me, and may be 
proxied or accepted based (from inside the sql procedure) based on 
information in the request other than username/password and should therefore 
go through the normal sql queries.

Cheers

Peter



On Thu 21 Sep 2006 01:48, Michael Griego wrote:
> There already is a DEFAULT profile that is checked for every user
> regardless of what groups they may or not may be in.  It would be
> easiest (and make the most sense, IMO) to just wrap everything before
> the profile check section (line 1018 in the CVS HEAD rlm_sql.c) in an
> "if (request->username != NULL)" block...  That way none of the
> radcheck/radreply and group checks for the normal username are done,
> it just skips straight to checking the default profile (or user
> profile if the attribute exists).
>
> --Mike
>
> On Sep 20, 2006, at 5:05 PM, Peter Nixon wrote:
> > Our patch needs a little work before its ready to be committed.
> > Currently to
> > save auditing the rest of the code we are rewriting null values to
> > "X" which
> > doesn't exist as a user in our database.
> >
> > We will spend some time tomorrow to write this patch correctly now
> > that I know
> > alan doesn't have anything against it. (It was just a hack to get us
> > operational)
> >
> > I also think that we should be able to have DEFAULT data in SQL
> > tables, but
> > this will require a whole new class of query to impliment correctly.
> > (Or a
> > second copy of the SQL module with the current code)
> >
> > Cheers
> >
> > On Wed 20 Sep 2006 19:26, Michael Griego wrote:
> >> How does your patch work, Peter?  Is it similar to what I described?
> >>
> >> --Mike
> >>
> >> On Sep 20, 2006, at 9:45 AM, Alan DeKok wrote:
> >>> Peter Nixon <listuser at peternixon.net> wrote:
> >>>> We have had to locally patch rlm_sql to make it accept NULL
> >>>> usernames. Is
> >>>> there any particular reason why it does this check?
> >>>> rlm_sql_postgresql works
> >>>> fine with NULL usernames as does the rest of FreeRADIUS.
> >>>
> >>>   Go for it.
> >>>
> >>>   Alan DeKok.
> >>> --
> >>>   http://deployingradius.com       - The web site of the book
> >>>   http://deployingradius.com/blog/ - The blog
> >>> -
> >>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
> >>> devel.html
> >>
> >> -
> >> List info/subscribe/unsubscribe? See
> >> http://www.freeradius.org/list/devel.html
> >
> > --
> >
> > Peter Nixon
> > http://www.peternixon.net/
> > PGP Key: http://www.peternixon.net/public.asc
> > -
> > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
> > devel.html
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20060921/cb140931/attachment.pgp>