Reject user from SQL-DB

[Phil Mayers]

JB wrote:
> 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]

Ah I see.

No, the "sql" module doesn't work that way - if *any* check pairs are 
returned (and match) the reply query is run, but the pairxlatmove() is 
done *after* the reply query is done - i.e. it does this:

check_items = sql(check_query)
if paircompare(request, check_items):
   reply_items = sql(reply_query)
   pairxlatmove(request->reply_items, reply_items)
   pairxlatmove(request->check_items, check_items)

The only way you could change this would be with source-code patches or 
use rlm_perl/python to do the logic you want.

Arguably the check items pairxlatmove() should be before the reply 
query, but then if the xlat of the reply query or reply query itself 
fail, you'd have added check items without corresponding reply items 
(but the module would have returned a fail error code, so it's probably 
not a big deal)

You could move the check items pairxlatmove() call - it's line 669 in 
src/modules/rlm_sql/rlm_sql.c in my copy of 2.0.0, and would need to 
move to just above line 651 i.e. the radius_xlat of the reply query.