invalid variable

[Alan DeKok]

Stelian Ionescu wrote:
> 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.

  The escaping is controlled by the "safe-characters" configuration in
SQL.  If you want to allow '?', edit that configuration item.

> 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.

  Because that's how the SQL escaping function works.  See?

  If you run the same xlat in a non-SQL context, you'll see '?' instead
of the hex encoded version.

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

  That shouldn't be happening.  It's taken from the packet timestamp,
which always gets initialized to the current time.

  Alan DeKok.