Skip to content
Snippets Groups Projects
  • Kevin Harwell's avatar
    53c11260
    AMI: Escape string values. · 53c11260
    Kevin Harwell authored
    So this issue is a bit complicated. Since it is possible to pass values to AMI
    that contain a '\r\n' (or other similar sequences) these values need to be
    escaped. One way to solve this is to escape the values and then pass the escaped
    values to the AMI variable parameter string building function. However, this
    puts the onus on the pre-build function to escape all string values. This
    potentially requires a fair amount of changes along with a lot of string
    allocations/freeing for all values.
    
    Surely there is a way to push this complexity down a level into the string
    building function itself? This of course is possible, but ends up requiring a
    way to distinguish between strings that need to be escaped and those that don't.
    The best way to handle this is by introducing a new format specifier in the
    format string. For instance a %s (no escape) and %S (escape). However, that is
    a bit weird and unexpected.
    
    So faced with those possibilities this patch implements a limited version of the
    first option. Instead of attempting to escape all string values this patch only
    escapes those values that make sense. This approach limits the number of changes
    and doesn't suffer from the odd format specifier problem.
    
    ASTERISK-24934 #close
    Reported by: warren smith
    
    Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0
    53c11260
    History
    AMI: Escape string values.
    Kevin Harwell authored
    So this issue is a bit complicated. Since it is possible to pass values to AMI
    that contain a '\r\n' (or other similar sequences) these values need to be
    escaped. One way to solve this is to escape the values and then pass the escaped
    values to the AMI variable parameter string building function. However, this
    puts the onus on the pre-build function to escape all string values. This
    potentially requires a fair amount of changes along with a lot of string
    allocations/freeing for all values.
    
    Surely there is a way to push this complexity down a level into the string
    building function itself? This of course is possible, but ends up requiring a
    way to distinguish between strings that need to be escaped and those that don't.
    The best way to handle this is by introducing a new format specifier in the
    format string. For instance a %s (no escape) and %S (escape). However, that is
    a bit weird and unexpected.
    
    So faced with those possibilities this patch implements a limited version of the
    first option. Instead of attempting to escape all string values this patch only
    escapes those values that make sense. This approach limits the number of changes
    and doesn't suffer from the odd format specifier problem.
    
    ASTERISK-24934 #close
    Reported by: warren smith
    
    Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0