Hello everyone, Do you guys know if there is a way to have variable expansion working when attributes are fetched from a SQL database? For example: Reply-Message := "Hello, %{User-Name}" I have a situation where I must use something like this only for a specific type of NAS. I could edit the configuration to do this conditionally in the post-auth section, but if it is possible with SQL it would be a cleaner solution. We use Freeradius 3.0.21 or later. -- Att, *Antônio Modesto*
On Mar 7, 2022, at 4:07 PM, Antônio Modesto <modesto@hubsoft.com.br> wrote:
Do you guys know if there is a way to have variable expansion working when attributes are fetched from a SQL database? For example:
Reply-Message := "Hello, %{User-Name}"
I have a situation where I must use something like this only for a specific type of NAS. I could edit the configuration to do this conditionally in the post-auth section, but if it is possible with SQL it would be a cleaner solution.
Yes. Just put the strings into SQL, and they will be expanded. Alan DeKok.
On 07/03/2022 18:13, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 7, 2022, at 4:07 PM, Antônio Modesto <modesto@hubsoft.com.br> wrote:
Do you guys know if there is a way to have variable expansion working when attributes are fetched from a SQL database? For example:
Reply-Message := "Hello, %{User-Name}"
I have a situation where I must use something like this only for a specific type of NAS. I could edit the configuration to do this conditionally in the post-auth section, but if it is possible with SQL it would be a cleaner solution.
Yes. Just put the strings into SQL, and they will be expanded.
That's odd, I tried that but the literal expression is returned in the Access-Accept: Vendor-Specific Attribute (26), length: 20, Value: Vendor: Unknown (6527) Vendor Attribute: 11, Length: 12, Value: %{User-Name}
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mar 8, 2022, at 7:48 AM, modesto@hubsoft.com.br wrote:
That's odd, I tried that but the literal expression is returned in the Access-Accept:
Hmm... it looks like that expansion is only done if the value contains back-ticks... `%{foo}`. Unfortunately we can't change this for 3.0. But I'll push a flag to the v3.2.x branch which will allow expansions in SQL replies. Alan DeKok.
On 08/03/2022 18:55, Alan DeKok wrote:
On Mar 8, 2022, at 7:48 AM, modesto@hubsoft.com.br wrote:
That's odd, I tried that but the literal expression is returned in the Access-Accept:
Hmm... it looks like that expansion is only done if the value contains back-ticks... `%{foo}`.
Unfortunately we can't change this for 3.0. But I'll push a flag to the v3.2.x branch which will allow expansions in SQL replies.
Should be able to use the 'xlat' xlat to force expansion, no? Something like update reply { &Tmp-String-0 := "%{xlat:&Tmp-String-1}" } But in either case I'd be very careful to ensure that the data coming from SQL is only set by the admin, and not from data in an incoming request. -- Matthew
On Mar 8, 2022, at 2:01 PM, Matthew Newton <mcn@freeradius.org> wrote:
Should be able to use the 'xlat' xlat to force expansion, no?
Something like
update reply { &Tmp-String-0 := "%{xlat:&Tmp-String-1}" }
It can be done, but only for each attribute, one by one.
But in either case I'd be very careful to ensure that the data coming from SQL is only set by the admin, and not from data in an incoming request.
Yeah. :( Alan DeKok.
On 08/03/2022 15:55, Alan DeKok wrote:
On Mar 8, 2022, at 7:48 AM, modesto@hubsoft.com.br wrote:
That's odd, I tried that but the literal expression is returned in the Access-Accept: Hmm... it looks like that expansion is only done if the value contains back-ticks... `%{foo}`.
Unfortunately we can't change this for 3.0. But I'll push a flag to the v3.2.x branch which will allow expansions in SQL replies.
Alan DeKok.
It really worked using back-ticks. Is there any chance that this will stop working in future versions?
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Att, *Antônio Modesto*
On Mar 8, 2022, at 3:05 PM, Antônio Modesto <modesto@hubsoft.com.br> wrote:
It really worked using back-ticks. Is there any chance that this will stop working in future versions?
No. Back-ticks are really for shell expansion / running shell programs. Using them here is a bit of a hack. 3.2 will remain backwards compatible with 3.0. We will add features, but features will never be removed. Alan DeKok.
participants (4)
-
Alan DeKok -
Antônio Modesto -
Matthew Newton -
modesto＠hubsoft.com.br