All Apps and Add-ons

How to escape double quotes in SideView Utils Textfield Module

jpass
Contributor

I have a dashboard that uses two SideView Utils TextField modules. The set up is as follows:

view
    textfield
        checkboxes
        checkboxes
   textfield
   button
   search
   table
view

The problem I'm having is in the search at the bottom I use the eval to set default values if the textfields are empty. If a user submits something with quotes, I always get an error:

"unbalanced quotes"

The parameters for the TextField parameters are only using the 'name' value with the others left as default. I did try to incorporate the 'template' as:

$value$

and
"$value$"

But the results are the same.

I also try using the ValueSetting module and sent one of the TextField values through it but the results seem the same.

So my question is basically: Is there a way to automatically escape any characters that might cause the downstream search to throw an error? My interpratation of the help documents is that the foo token $*.value$ should send a fully escape value that can be used within a search. In another dashboard I ended up using a custombehavior to help with this.

Thanks, -jp

0 Karma
1 Solution

sideview
SplunkTrust
SplunkTrust

The module param reference text warns you sternly to make sure that you actually need this param, but in your particular case I think you do. It's called backslashEscapeKeys and it's a param on the ValueSetter module.

If you do this sort of thing illustrated below, the end-result $foo$ will have properly backslash-escaped double quote and backslash characters.

<module name="TextField">
  <param name="name">foo</param>
  <param name="label">Foo</param>

  <module name="ValueSetter">
    <param name="name">foo</param>
    <param name="value">$foo.rawValue$</param>
    <param name="backslashEscapeKeys">foo.rawValue</param>

Note that if someone else reading this ONLY needs backslash characters escaped, then do not use ValueSetter here. the $foo$ token itself will already have backslash chars escaped.

And the reason it's $foo.rawValue$ going into ValueSetter and coming out as $foo$, is that $foo$ will already have backslash-escaped backslash characters, but NOT backslash-escaped double quotes. So if we were to send $foo$ in as the value of ValueSetter, whenever there were backslash characters in input, you'd end up with double-escaped backslash chars, and that would be bad.

Overly Verbose Background:

TextField, Pulldown, and all the "pulldown-cousins" - Radio,Tabs,Checkboxes, will automatically backslash-escape any backslash characters they run into. For an example of what this means - this is why end-users don't have to type "C:\myDir" into a TextField, they can just type "C:\myDir". The TextField's $foo$ token will have that backslash char with two backslashes.

However despite the treatment of backslash characters, these modules do not escape double quotes. In fact a recent attempt to update them to make them do so actually had to be reverted in a single business day (!). The reason is that quite a few uses cases out there have Pulldown values that are themselves whole swaths of search language. And similar use cases exist, for example when TextField is used as a "miscellaneous search terms" field. So a significant minority of use cases actually need the double quotes to NOT be escaped.

I'm still considering whether all these modules should get some param that amounts to "escapeForSearchLanguage", that has some values like "True", "False", and "onlyBackslashes", with the last being the default simply because that is the behavior to date. =/

However it wont be any time soon because this direction is fraught with peril. If you experiment with the full list chars like \, ", [, ], , |, you have some very problematic ones in there. Some need to be quoted and not backslash escaped, and to take an extreme example "" actually cannot be escaped, at least not in search. In search it is always a wildcard.

So... what we're left with for now, is this ValueSetter trick.

View solution in original post

sideview
SplunkTrust
SplunkTrust

The module param reference text warns you sternly to make sure that you actually need this param, but in your particular case I think you do. It's called backslashEscapeKeys and it's a param on the ValueSetter module.

If you do this sort of thing illustrated below, the end-result $foo$ will have properly backslash-escaped double quote and backslash characters.

<module name="TextField">
  <param name="name">foo</param>
  <param name="label">Foo</param>

  <module name="ValueSetter">
    <param name="name">foo</param>
    <param name="value">$foo.rawValue$</param>
    <param name="backslashEscapeKeys">foo.rawValue</param>

Note that if someone else reading this ONLY needs backslash characters escaped, then do not use ValueSetter here. the $foo$ token itself will already have backslash chars escaped.

And the reason it's $foo.rawValue$ going into ValueSetter and coming out as $foo$, is that $foo$ will already have backslash-escaped backslash characters, but NOT backslash-escaped double quotes. So if we were to send $foo$ in as the value of ValueSetter, whenever there were backslash characters in input, you'd end up with double-escaped backslash chars, and that would be bad.

Overly Verbose Background:

TextField, Pulldown, and all the "pulldown-cousins" - Radio,Tabs,Checkboxes, will automatically backslash-escape any backslash characters they run into. For an example of what this means - this is why end-users don't have to type "C:\myDir" into a TextField, they can just type "C:\myDir". The TextField's $foo$ token will have that backslash char with two backslashes.

However despite the treatment of backslash characters, these modules do not escape double quotes. In fact a recent attempt to update them to make them do so actually had to be reverted in a single business day (!). The reason is that quite a few uses cases out there have Pulldown values that are themselves whole swaths of search language. And similar use cases exist, for example when TextField is used as a "miscellaneous search terms" field. So a significant minority of use cases actually need the double quotes to NOT be escaped.

I'm still considering whether all these modules should get some param that amounts to "escapeForSearchLanguage", that has some values like "True", "False", and "onlyBackslashes", with the last being the default simply because that is the behavior to date. =/

However it wont be any time soon because this direction is fraught with peril. If you experiment with the full list chars like \, ", [, ], , |, you have some very problematic ones in there. Some need to be quoted and not backslash escaped, and to take an extreme example "" actually cannot be escaped, at least not in search. In search it is always a wildcard.

So... what we're left with for now, is this ValueSetter trick.

jpass
Contributor

That is the issue. I have 2.5 Thanks.

0 Karma

sideview
SplunkTrust
SplunkTrust

Make sure you have at least version 2.6. Any earlier than that and the backslashEscapeKeys will literally only escape backslash characters, not double quotes. I should have mentioned that. If yours is older, update to latest (2.6.3) http://sideviewapps.com/apps/sideview-utils

0 Karma

jpass
Contributor

Thanks for the detailed answer (as usual). I have not accepted yet because I've tried this before I posted the question and after and it still seems not to work. I'm going to revisit it again on Monday and if it's not something I'm doing wrong I'll post some XML and if you don't mind taking a look.

0 Karma

jpass
Contributor

fyi, I mentioned quotes but really what I need is to escape any character that would break the search.

0 Karma
Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...