Phil Mayers:
JB wrote:
I'm sorry, I have to ask again. Have you found a way to let the
reply query know that the user has already been rejected in the
check-query? I'm trying to avoid executing the same queries twice
and also to avoid using temporary tables.
I thought I'd answered this?
"""What you could do is place a local attribute in the check items,
then copy it to the reply items in an unlang section..."""
Which you said worked in a later email
Sorry if I haven't made myself clear enough. These were two different
things.
On the on hand, I wanted to return a Reply-Message to the user which
is set in one of the two queries, which works fine the way you proposed.
On the other hand, I wanted to avoid executing unnecessary sub-queries
in the reply query (a stored procedure in my case), or the reply query
itself, if the user has already been rejected in the check query. It
seems that the reply query is always executed. And if I call the
stored procedure with attributes like "%{control:Auth-Type}" or "%
{control:My-Reply}", they don't get resolved although they're set in
the first query.
In pseudo-code:
Check query: reject user because of reason 'xyz', set My-Attr to
'xyz'. [works]
If rejected, don't call reply query (or at least call reply query with
resolved attributes to avoid unnecessary sub-queries) [doesn't work]
If rejected copy My-Attr to Reply-Message [works]
JB
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
