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(
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
