On Wed, May 18, 2016 at 12:05:37PM +0100, Phil Mayers wrote:
On 18/05/16 11:51, Jakob Hirsch wrote:
I am currently in the process of migrating our 2.2.9 setup to 3.0.11 and, naturally, stumbled over a few things (i.e. more messages will follow).
It seems that SQL-User-Name is not usable in expansions any more, only when calling the module (we use authorize_check_query and authorize_reply_query).
Yeah, we ran into that. Annoying.
Hmm. Bug, but I can't see an easy way to fix it. The sql xlat does correctly add SQL-User-Name to the request with the right value. The problem is that xlat has already expanded all attributes before passing the string through to the sql module xlat. And of course at that time SQL-User-Name didn't exist. You can show this by doing # User-Name = "bob" # (SQL-User-Name here doesn't exist) update request { Tmp-String-1 := "%{sql:select '%{SQL-User-Name}'}" # this expands to "select ''" } # (SQL-User-Name here is "bob") update request { User-Name := 'jimbo' } update request { Tmp-String-1 := "%{sql:select '%{SQL-User-Name}'}" # this expands to "select 'bob'" } # SQL-User-Name here is "jimbo" So SQL-User-Name lags behind by one xlat.
I did this at the top-level of radiusd.conf:
sqlusername = "%{%{Stripped-User-Name}:-%{User-Name}}"
...and then did this everywhere:
update { blah = "${sqlusername}" }
...to save on typing.
Probably the easiest way without radius_xlat calling some sort of module "pre-xlat" function before doing the xlat. Or having a "delayed expansion" flag which tells radius_xlat not to expand anything and to let the module do it. But I guess that's what happened before; it was probably fixing all the \\\\\\\\ escaping madness that broke this... Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>