You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the Mustache template syntax {{variable name}}, you can pass alert values at the time a condition is detected to an action. Note that using two curly braces will escape any HTML. Should you need to preserve HTML, use three curly braces ({{{). Available variables differ by alert type, and a list can be accessed using the "add variable" button.
What's not quite right about it is that we changed the way we do escaping, so that most of the time, there is no longer any escaping going on at all, as it's not really needed. We should not be referencing HTML at all, as we no longer do any HTML escaping ever.
Previously, we always escaped every context variable for every action parameter template as HTML. Because that's what the version of mustache we are using does.
With PR #83919 , this changed. We now only escape three action parameter templates - message for email and slack, and body for webhook. In all cases, the escaping we do is the escaping of the format the parameters are intended to be in; Markdown escaping for message for email, Slack markdown escaping for message in slack, and JSON escaping for body in webhook.
At this point, it's unlikely that anyone should have to use triple braces - because we're doing more precise escaping than we were before. Folks used to use triple braces so that you wouldn't see < chars turned into < (or anything that would need to be escaped for HTML). With the new escaping, it should do the right thing, all the time.
There's still a potential that customers may need to use triple braces, if eg our escaping logic is not correct, or they REALLY want the data in the context parameters to be interpreted as markdown (seems a stretch, but ???; eg of this would be some context variable having the value *some text*, where the customer would want those asterisks interpreted as "Slack bold formatting"). However, using triple braces now could potentially mess up the expected formatting for the action parameters that we do escaping for. Eg, if you use triple braces in the JSON body of a webhook, and the variable in the braces contains a newline character, it won't be escaped and will end up rendering the JSON as unparseable (one of the problems that caused us to fix the escaping). So we definitely should not recommend it be used. Mentioning that it can be used seems fine, but makes me wonder if we can describe all this in an easy-to-comprehend way.
The text was updated successfully, but these errors were encountered:
The current docs for mustache escaping of alert context variables in action parameter templates isn't quite right - from about 2/3 down on the page https://www.elastic.co/guide/en/kibana/7.11/defining-alerts.html :
What's not quite right about it is that we changed the way we do escaping, so that most of the time, there is no longer any escaping going on at all, as it's not really needed. We should not be referencing HTML at all, as we no longer do any HTML escaping ever.
Previously, we always escaped every context variable for every action parameter template as HTML. Because that's what the version of mustache we are using does.
With PR #83919 , this changed. We now only escape three action parameter templates -
message
for email and slack, andbody
for webhook. In all cases, the escaping we do is the escaping of the format the parameters are intended to be in; Markdown escaping formessage
for email, Slack markdown escaping formessage
in slack, and JSON escaping forbody
in webhook.At this point, it's unlikely that anyone should have to use triple braces - because we're doing more precise escaping than we were before. Folks used to use triple braces so that you wouldn't see
<
chars turned into<
(or anything that would need to be escaped for HTML). With the new escaping, it should do the right thing, all the time.There's still a potential that customers may need to use triple braces, if eg our escaping logic is not correct, or they REALLY want the data in the context parameters to be interpreted as markdown (seems a stretch, but ???; eg of this would be some context variable having the value
*some text*
, where the customer would want those asterisks interpreted as "Slack bold formatting"). However, using triple braces now could potentially mess up the expected formatting for the action parameters that we do escaping for. Eg, if you use triple braces in the JSON body of a webhook, and the variable in the braces contains a newline character, it won't be escaped and will end up rendering the JSON as unparseable (one of the problems that caused us to fix the escaping). So we definitely should not recommend it be used. Mentioning that it can be used seems fine, but makes me wonder if we can describe all this in an easy-to-comprehend way.The text was updated successfully, but these errors were encountered: