invalid variable

[Stelian Ionescu]

On Wed, 2013-06-05 at 09:15 -0400, Alan DeKok wrote:
> Stelian Ionescu wrote:
> > Take for instance the expansion of '%{Nas-Ip-Address}'::inet from that
> > trace: it's '=3F.=3F.=3F.=3F'::inet which looks like an url-encoding of
> > "?.?.?.?". I can't imagine how this can be since the debug output from
> > rlm_perl, which prints all VPs in the request, shows that the actual
> > value is correct so my only guess is that the xlat function is somehow
> > buggy.
> 
>   Ah.  Let me guess... you're running the query from the inner-tunnel,
> and you didn't set "copy_request_to_tunnel = yes".
> 
>   The "?.?.?.?" output is produced when the NAS-IP-Address attribute
> doesn't exist.  Since you say it exists, the only place it normally
> doesn't exist is in the inner-tunnel.

It's true that copy_request_to_tunnel wasn't set to "yes", but the
problem still remains in that radius_axlat() didn't output a literal '?'
but its hex-encoding, and that's caused by the way sql escaping is
currently done.

Give these request VPs:

Event-Timestamp = 'Jun  7 2013 18:02:09 CEST'
SQL-User-Name = 'test'

then the SQL fragment

«COALESCE(NULLIF('%{Event-Timestamp}', ''), '%S')::timestamp with time zone,'%{SQL-User-Name}'»

gets translated into

«COALESCE(NULLIF('Jun  7 2013 18:02:09 CEST=27=2C =27=27=29=2C =271970-01-01 01:00:00=27=29::timestamp with time zone=2C=27test'»

Notice how the apostrophes and commas are getting hex-encoded, thereby
making the resulting query invalid.

Another strange thing in that expansion is that %S now gets consistently
expanded to «1970-01-01 01:00:00»

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20130611/3efd4fae/attachment.pgp>