Watcher reporting basic auth not working, password not saved

Elastic Stack Elasticsearch
1

Hello,

this watcher below is not working for me. Whenever I add the password field, it doesn't get saved. I thought it was only hidden, but running the watcher returns: "Watcher: [parse_exception] password is a required option".
I can send other emails with the same default account with no issues, but I can't generate reports if I can't authenticate.

{
"trigger": {
"schedule": {
"interval": "1m"
}
},
"input": {
"none": {}
},
"condition": {
"always": {}
},
"actions": {
"send_email": {
"email": {
"profile": "standard",
"attachments": {
"SDC_daily_count.pdf": {
"reporting": {
"url": "http://x.x.x.x/api/reporting/generate/dashboard/SDC-daily-count",
"auth": {
"basic": {
"username": "elastic",
"password": "changeme" ###THIS GETS REMOVED###
}
}
}
}
},
"to": [
"aaa@bbb.com"
],
"subject": "SDC daily counts"
}
}
}
}

2

can you create a full reproduction case, including the complete API calls to create the watch and the output of the execute watch API?

Also, what Elasticsearch version is this?

--Alex

3

Hello Alex,
thank you for your prompt reply!

I am using v5.6.4 of ES and Kibana.
This is the execution output:

{
"watch_id": "SDC_test_daily",
"state": "executed",
"status": {
"state": {
"active": true,
"timestamp": "2017-11-21T16:48:48.539Z"
},
"last_checked": "2017-11-21T17:09:00.612Z",
"last_met_condition": "2017-11-21T17:09:00.612Z",
"actions": {
"send_email": {
"ack": {
"timestamp": "2017-11-21T16:48:48.539Z",
"state": "awaits_successful_execution"
},
"last_execution": {
"timestamp": "2017-11-21T17:09:00.612Z",
"successful": false,
"reason": "Connection refused"
}
}
}
},
"trigger_event": {
"type": "schedule",
"triggered_time": "2017-11-21T17:09:00.612Z",
"schedule": {
"scheduled_time": "2017-11-21T17:09:00.567Z"
}
},
"input": {
"none": {}
},
"condition": {
"always": {}
},
"result": {
"execution_time": "2017-11-21T17:09:00.612Z",
"execution_duration": 2,
"input": {
"type": "none",
"status": "success",
"payload": {}
},
"condition": {
"type": "always",
"status": "success",
"met": true
},
"actions": [
{
"id": "send_email",
"type": "email",
"status": "failure",
"reason": "Connection refused"
}
]
},
"messages": []
}

To create the watch, I just used the json in my previous post in the kibana GUI. It doesn't give any syntax error. If I go back to edit the watch, the password field is gone.

Thanks,
Tommaso

4

the error message from what you pasted is not what you referred to before. Has anything changed? Seems like kibana is not reachable or the mail server.

5

The error message comes from that watch scheduled execution.
If I simulate the watch from kibana, I get:

Watcher: [parse_exception] password is a required option

6

While troubleshooting, I created another watch, just to test the email server. This one works just fine and I ge the email in my inbox:

{
"trigger": {
"schedule": {
"interval": "1m"
}
},
"input": {
"search": {
"request": {
"search_type": "query_then_fetch",
"indices": [
"*"
],
"types": [],
"body": {
"size": 0,
"query": {
"match_all": {}
}
}
}
}
},
"condition": {
"compare": {
"ctx.payload.hits.total": {
"gte": 10
}
}
},
"actions": {
"send_email": {
"email": {
"profile": "standard",
"to": [
"aaa@bbb.com"
],
"subject": "Watcher Notification Test",
"body": {
"text": "This is a test"
}
}
}
}
}

7

Experiencing similar issue (we opened a similar ticket on v5.6.3 about 19m after this one was opened - crazy!) - watching both threads for a solution...

Simulating the watcher, before saving it, seems to trigger fine

Once I SAVE the JSON definition, the "password" element in the JSON is parsed out by the Kibana server as it is performing the save action.

Re-opening the watch and attempting to simulate then produces the error:
Watcher: [parse_exception] password is a required option

This seems to be a "feature" as reported here :

So... irritating messaging? Is there anyway to get a different, more explicit, message :slight_smile:

8

Hey,

indeed, this a feature from watchers GET Watch API, that removes passwords, when data is returned to kibana. In this special case, the credentials should not get removed, as otherwise storing the watch fails - what you are experiencing.

I will work with the UI team on a fix. Sorry for the inconvenience.

--Alex

9

Thank you Alex! Do you know if this is fixed in v6.0? I am running an evaluation, non-production environment, so I can upgrade anytime.

Thanks,
Tommaso

10

Hey Tommaso,

no, it's not, the behaviour is the same.

--Alex

11

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.