Reject user from SQL-DB

[Phil Mayers]

JB wrote:
>>> Return:
>>>
>>> attr = 'Auth-Type'
>>> op = ':='
>>> value = 'Reject'
>>
>> Of course! How embarrassing. ;-)
>> I actually tried that before but during the reply-items-query which 
>> has no effect. Returning Auth-Type := Reject from the 
>> check-items-query does the trick. Makes sense, doesn't it?
> 
> Ok, now I'm returning Auth-Type := Reject from my check-items-query and 
> I hoped to be able to send a little more in depth information along the 
> way in the Reply-Message attribute, but unfortunately this info gets 
> lost. It seems that I have to fill this attribute in the reply-items-query.
> 
> Does this mean the reply-items-query has to trigger the same functions 
> as the check-items-query again to find out what the reason for the 
> reject was? Or do I have to fill a temporary table with the reply 
> message in the check-items-query which gets then returned in the 
> reply-items-query?

Hmm. I guess you're doing something like:

authorize_check_query = "select myproc('%{SQL-User-Name}','...etc...')"

...and are trying to avoid re-calling the same (or another) function in 
the reply query.

What you could do is place a local attribute in the check items, then 
copy it to the reply items in an unlang section:

i.e. return 2 rows from the stored proc:

    attr    | op |    value
-----------+----+--------------
  My-Reply  | := | some message
  Auth-Type | := | Reject

in /etc/raddb/dictionary:

ATTRIBUTE My-Reply 3000 string

and have:

authorize {
   sql
}
post-auth {
   Post-Auth-Type Reject {
     if (control:My-Reply) {
       update reply {
         Reply-Message = "%{control:My-Reply}"
       }
     }
   }
}

...be aware however that almost *nothing* pays any attention to 
Reply-Message :o(