Question regarding scripted fields

[mordax7]

We currently got the version v210.3.0 of the logsearch for cloudfoundry deployed. One of our tenants found out that when he tries to create a scripted field in Kibana he will get a 500 returned in the preview, same goes when he was trying to save it. When trying to recreate the problem. with our users that are permitted on the system organisation, we were not able to do it. The API call sent to Kibana for the creation of the scripted field is a POST on /_filtered_msearch. Error Log entry:

{"type":"error","@timestamp":"2020-05-05T09:47:36Z","tags":[],"pid":5181,"level":"error","error":{"message":"[parsing_exception] [match_all] malformed query, expected [END_OBJECT] but found [FIELD_NAME], with { line=1 & col=26 }","name":"Error","stack":"[parsing_exception] [match_all] malformed query, expected [END_OBJECT] but found [FIELD_NAME], with { line=1 & col=26 } :: {\"path\":\"/_msearch\",\"query\":{},\"body\":\"{\\\"index\\\":\\\"logs-app*\\\",\\\"ignore_unavailable\\\":true}\\n{\\\"query\\\":{\\\"match_all\\\":{},\\\"bool\\\":{\\\"must\\\":[{\\\"terms\\\":{\\\"@cf.space_id\\\":[]}},{\\\"terms\\\":{\\\"@cf.org_id\\\":[]}}]}},\\\"script_fields\\\":{\\\"testi2\\\":{\\\"script\\\":{\\\"lang\\\":\\\"painless\\\",\\\"source\\\":\\\"return \\\\\\\"does it work\\\\\\\"\\\"}}},\\\"size\\\":10,\\\"timeout\\\":\\\"30s\\\"}\\n\",\"statusCode\":400,\"response\":\"{\\\"error\\\":{\\\"root_cause\\\":[{\\\"type\\\":\\\"parsing_exception\\\",\\\"reason\\\":\\\"[match_all] malformed query, expected [END_OBJECT] but found [FIELD_NAME]\\\",\\\"line\\\":1,\\\"col\\\":26}],\\\"type\\\":\\\"parsing_exception\\\",\\\"reason\\\":\\\"[match_all] malformed query, expected [END_OBJECT] but found [FIELD_NAME]\\\",\\\"line\\\":1,\\\"col\\\":26},\\\"status\\\":400}\"}\n    at respond (/var/vcap/data/packages/kibana/3844b6c736cf71201c7b67b522f7e356b03c7a2b/node_modules/elasticsearch/src/lib/transport.js:308:15)\n    at checkRespForFailure (/var/vcap/data/packages/kibana/3844b6c736cf71201c7b67b522f7e356b03c7a2b/node_modules/elasticsearch/src/lib/transport.js:267:7)\n    at HttpConnector.<anonymous> (/var/vcap/data/packages/kibana/3844b6c736cf71201c7b67b522f7e356b03c7a2b/node_modules/elasticsearch/src/lib/connectors/http.js:166:7)\n    at IncomingMessage.wrapper (/var/vcap/data/packages/kibana/3844b6c736cf71201c7b67b522f7e356b03c7a2b/node_modules/elasticsearch/node_modules/lodash/lodash.js:4935:19)\n    at IncomingMessage.emit (events.js:194:15)\n    at endReadableNT (_stream_readable.js:1103:12)\n    at process._tickCallback (internal/process/next_tick.js:63:19)"},"url":{"protocol":null,"slashes":null,"auth":null,"host":null,"port":null,"hostname":null,"hash":null,"search":null,"query":{},"pathname":"/elasticsearch/_msearch","path":"/elasticsearch/_msearch","href":"/elasticsearch/_msearch"},"message":"[parsing_exception] [match_all] malformed query, expected [END_OBJECT] but found [FIELD_NAME], with { line=1 & col=26 }"}
{"type":"response","@timestamp":"2020-05-05T09:47:36Z","tags":[],"pid":5181,"method":"post","statusCode":500,"req":{"url":"/elasticsearch/_msearch","method":"post","headers":{"x-forwarded-for":"148.251.234.157","x-forwarded-proto":"https","x-forwarded-port":"443","x-amzn-trace-id":"Root=1-5eb137a7-82e68d74820bf4cae50213c1","content-length":270,"dnt":"1","kbn-version":"6.8.1","content-type":"application/json","accept":"*/*","origin":"https://DEDUCTED_URL","sec-fetch-site":"same-origin","sec-fetch-mode":"cors","sec-fetch-dest":"empty","referer":"https://DEDUCTED_URL/app/kibana","accept-language":"en-US,en;q=0.9,de;q=0.8","user-agent":"shot","host":"0.0.0.0:5601"},"remoteAddress":"127.0.0.1","userAgent":"127.0.0.1","referer":"https://DEDUCTED_URL/app/kibana"},"res":{"statusCode":500,"responseTime":30,"contentLength":9},"message":"POST /elasticsearch/_msearch 500 30ms - 9.0B"}

Since it had to do something with the permissions we knew we should take a loot at trhe Kibana Cloud Foundry authentication plugin. So after analyzing the plugin we found out that the problem happens somewhere around: https://github.com/cloudfoundry-community/logsearch-for-cloudfoundry/blob/6882b0cf6ac4df8fb3b8b8337549c4b7f668cef5/src/kibana-cf_authentication/server/routes.js#L86 Since it seems like when the user is not part of the cf_system_org the payload is in a somehow broken state, it will be still sent in the like 99-100.

After some more investigation, we found out that the new release includes 96533564a499f97531afa44fa859407bdf7b4ce6 commit. Which opened even more questions since we could not find any issues to this topic nor any other comments explaining if this feature was ever tested or worked at the first place.

Is the problem fixed with that commit? Does the problem still persist in the latest release?

Thanks for your help!

UPDATE1: Solved the problem with the not able to see the scripted field after creating them in the list, had to select the index on which it was created.