Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[alerts][actions] malformed JSON in webhook body param throws JSON error #81849

Open
pmuellr opened this issue Oct 27, 2020 · 4 comments
Open
Labels
bug Fixes for quality problems that affect the customer experience estimate:medium Medium Estimated Level of Effort Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Oct 27, 2020

Kibana 7.9.3

If you create a webhook in an any type of alert, whose body parameter is the following string, you can save the alert, but when trying to edit it again, a JSON error will be thrown and the display will end up being cleared.

{
    "text": "{{context.matchingDocuments}} events
{{context.conditions}}\n\n{{#toJson}}context{{/toJson}}"
}

Technically, JSON where there's a literal \n in a property, like above, can cause issues, typically when sending the final rendered JSON to a webhook service. Eg, see issue #79371

In this case though, we're seeing an issue when we try to edit the alert again, and the webhook body param editor is hitting a problem.

From the CDT console, the JSON.parse() that's throwing the error is the one in this snippet of code:

if (!skip && candidate.match(/\\./)) {
result += `"""${JSON.parse(candidate)}"""`;
} else {
result += candidate;
}

This is the code which "triple double quotes" strings like we do for Kibana Dev Console, but I don't think we want that behavior for the JSON we're editing in alerts/actions.

@pmuellr pmuellr added bug Fixes for quality problems that affect the customer experience Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Oct 27, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@pmuellr
Copy link
Member Author

pmuellr commented Oct 27, 2020

Playing with this a bit more, when I change the body to remove the embedded newline, I have no issues saving and re-editing the alert:

{
    "text": "{{context.matchingDocuments}} events {{context.conditions}}\n\n{{#toJson}}context{{/toJson}}"
}

However, the alert does get displayed as a "triple double quoted" string in Kibana:

{
    "text": """{{context.matchingDocuments}} events {{context.conditions}}

{{#toJson}}context{{/toJson}}"""
}

I'm not a fan of this, since "triple double quoted" strings aren't a standard of any kind, and so it means I can't simply cut&paste a JSON body like this somewhere else to use with other tools (ie, while developing the alert).

As near as I can tell, the conversion from triple/double to standard JSON is taking place when the alert is saved, as I can see the following in the alert's JSON when I curl it from the console:

"params": {
    "body": "{\n    \"text\": \"{{context.matchingDocuments}} events {{context.conditions}}\\n\\n{{#toJson}}context{{/toJson}}\"\n}"
},

@mikecote
Copy link
Contributor

Moving from 7.12 - Candidates to 7.x - Candidates.

@mikecote
Copy link
Contributor

mikecote commented Feb 5, 2021

Moving from 7.x - Candidates to 7.13 after the latest 7.x planning session. If we get time, we will try to implement something simple for this.

@gmmorris gmmorris added the Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework label Jul 1, 2021
@gmmorris gmmorris added the loe:large Large Level of Effort label Jul 15, 2021
@gmmorris gmmorris added the estimate:medium Medium Estimated Level of Effort label Aug 18, 2021
@gmmorris gmmorris removed the loe:large Large Level of Effort label Sep 2, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience estimate:medium Medium Estimated Level of Effort Feature:Alerting/RuleActions Issues related to the Actions attached to Rules on the Alerting Framework Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
Development

No branches or pull requests

5 participants