[asterisk-bugs] [Asterisk 0014614]: [patch] func_odbc's OPT_ESCAPECOMMA's is undone by second ast_app_separate_args call when using Set(ARRAY...)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14614 
====================================================================== 
Reported By:                wdoekes
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   14614
Category:                   Functions/func_odbc
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 180528 
Request Review:              
====================================================================== 
Date Submitted:             2009-03-06 07:20 CST
Last Modified:              2009-03-17 02:42 CDT
====================================================================== 
Summary:                    [patch] func_odbc's OPT_ESCAPECOMMA's is undone by
second ast_app_separate_args call when using Set(ARRAY...)
Description: 
When returning more than one column with func_odbc custom functions, the
comma's that should separate the columns are not escaped. This happens when
setting the variables through the ARRAY function:

=== Example ===

(extensions.conf)
exten => _X.,1,Set(ARRAY(a|b)=${MY_ODBC_FUNC()}) 

(func_odbc.conf)
read=SELECT 'column, with comma', 1

The above results in:
${a} == "column", ${b} == ", with comma"
instead of:
${a} == "column, with comma", ${b} == 1

=== Cause ===

ast_app_separate_args is called twice on
"""ARRAY(a|b)=value\, with comma,1"""
once in pbx_builtin_setvar() (pbx.c) and once in array() (func_strings.c)
(through AST_NONSTANDARD_APP_ARGS).

The first one removes all the backslashes but doesn't split the arguments
because the delimiter is '|'.

Then you have """value, with comma,1""" which is split in three parts.

=== Problem ===

The problem lies in the double unescaping of the backslash and has nothing
to do with func_odbc per se. To set multiple variables at once, one must
do:

exten => _X.,1,Set(ARRAY(a|b|c)=1\\|2\\|3)
(double escape)

=== Solution ===

I don't know if the double unescaping is intended (according to my
O'Reilly book for 1.4 it isn't). When writing a Set statement without odbc
functions, one can double escape the comma, or resort to multiple Set
statements.

When using func_odbc, double-escaping the comma's could be a workaround.
See the attached patch.
====================================================================== 

---------------------------------------------------------------------- 
 (0101848) wdoekes (reporter) - 2009-03-17 02:42
 http://bugs.digium.com/view.php?id=14614#c101848 
---------------------------------------------------------------------- 
For those that also have this issue, my current solution is as follows.

I create a MySQL function ASTERISK_ESCAPE and use that one to wrap all my
columns (i.e. SELECT ASTERISK_ESCAPE(my_column),
ASTERISK_ESCAPE(my_2nd_column)):

CREATE FUNCTION ASTERISK_ESCAPE (str VARCHAR(512)) RETURNS VARCHAR(512)
  RETURN REPLACE(REPLACE(REPLACE(REPLACE(str,
  '\\', '\\\\\\\\'), ',', '\\\\\\,'), '|', '\\\\\\|'), '"',
'\\\\\\\\\\\\\\"');

This particular function only works in the following condition:
(1) You must set escapecommmas=no (the function purposefully
double-escapes)
(2) It only works for multiple-column gets:
Set(ARRAY(a,b,c)=${MY_ODBC_FUNC()}) (otherwise single escape would be
appropriate)
(3) The double-quote is triple escaped. This is because I used the output
as input to CALLERID(name) and that one doesn't escape double-quotes on my
tested version (yielding invalid SIP headers or even header injection
bugs). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-17 02:42 wdoekes        Note Added: 0101848                          
======================================================================