Helle,
We use ROR 1.35.0 ans ES 7.12.1,
when i use somme request GET or POST with Dev tools, for example :
GET /_index_template/
i have this error :
{
“error” : {
“root_cause” : [
{
“type” : “illegal_argument_exception”,
“reason” : “request [GET /_index_template/] does not support having a body”
}
],
“type” : “illegal_argument_exception”,
“reason” : “request [GET /_index_template/] does not support having a body”
},
“status” : 400
}
Can you Help us please,
Thank you
Hello @belotfi thanks for reporting this issue. We alreaady have a fix for this, and it will be present in the next release 1.36.0 which is due this weekend.
Hello Simon, Thank you, we wait the next release
Hi Simone,
it’s working now with ROR 1.36.0 for GET /_index_template/
but when i try to use this request with _bulk :
POST /xx-enrich-iis/_bulk
{ "index" : { } }
{ "nom": "ORCHESTxxx", "env_logique": ["Traitements xxxx","GSA xxx - xx - 01 : (xxxxI01)","Traitements de xxxx","Traitements xxx"], "niveau": "accepxxx" }
{ "index" : { } }
{ "nom": "ORCHESTRATEURFOR", "env_logique": ["Traitements xx","GSA xxx - EI - 01 : (xxxI01)","Traitements xxx","Traitements xxx"], "niveau": "formxxx" }
{ "index" : { } }
I got this :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Bad Request</pre>
</body>
</html>
Thank you Simon for HelpThanks @belotfi. We’ll have a look!
Hello @belotfi. Thanks for your message. I can confirm that we found a bug related to POST _bulk on a plugin side, we are working on fixing it now
Is it possible to tell us when it will be available since we are strugling with ROR serveral months ago and each time there is a bug. I’m wondering if you perform tests with a good coverage before releasing a new versions !!! Now we have to meet a business deadlinne. we have missed several deliveries due to these problems and we are starting to doubt the reliability of the choice of ROR
Hello @abdamou, thank you for feedback.
As a matter of fact, this morning @Dzuming took the time to add an extensive integration test suite dedicated to devtools alone. But yes, you are right we underestimated Devtools Kibana app and its apparent simplicity. It turned out having a few corner cases.
The initial bug: we always parse the body into JSON, which generated an empty object (even when dev tools request content-type wasn’t application/json). This caused does not support having a body error.
POST _bulk kibana request body had content-type application/json but carried invalid JSON (non-standard double quotes, for some reason) so when we tried to parse it, it causes a 400 bad request error.
We won’t try to parse the body of ANY dev tools console request, as we really don’t make use of it in ROR logic after all.
Maybe @Dzuming can confirm/correct me, but knowing his speed and typical work hours, I predict this fix will be delivered within the current day.
We will send you a pre-build ready to be installed.
By the way, please let us know if there are any other “hot spots” in Kibana functionality that are critical for your business case, and we should especially keep an eye on. We would be happy go beyond automated tests and go over those use cases manually.
Let me remark that as you are an enterprise customer, our support engineers, and myself are always at your disposal with top priority.
OK we talke through this incident internally. Then we took some time to rethink and level-up this piece of code togethr with the whole way we approach testing in the Kibana plugins.
Up to now, we have:
Deleted the old code who caused/could cause this kind of issues with Devtools and other apps.
Automated integration tests via Cypress.io running after every commit (previously we used to run it manually just before releasing)
One Cypress.io suite is generic for Kibana multi-tenancy
The other Cypress.io suite is specific for DevTools
Give us some time tonight to review and merge all the PRs and we can deliver this. Once again, thanks for sharing your feedback.
@abdamou we provided you with a build that fixes the issue, see the private messages in the forum.
Hi Simone,
its correct with _bulk problem
but with the new version 1.37 we have a security problem, a read-only user has the right to import saved objects
Can we hide the "Actions "section.
See attached files.
Thanks
Yes you can hide it with kibana_hide_apps: [ror|kibana], but even if you visualise that menu as read-only user you should get a 403 from elasticsearch.
Hi Simone,
We can’t hide readonlyrest action section in Kibana,
please see attached file :
Sorry @belotfi this was my mistake: the string I suggesed you from the top of my head was only a proposed solution. The final version of the strings to hide those menus are:
kibana_hide_apps: [ "ROR Manage Kibana" ] ← hides “Manage Kibana”
kibana_hide_apps: [ "'ROR Security Settings" ] ← hides “Security Settings” (applicable for “unrestricted” and “admin” kibana_access levels
the configuration to hide “Manage Kibana” works but to hide the “Security Settings” the " `kibana_hide_apps: [ “ROR Security Settings” ]" does not work
@Dzuming can you check this? It should totally work in 1.37.0-pre5 as far as I can tell.
PS: good opportunity to add some integration tests coverage about this aspects!
Hello @Nadine
Thanks for your message, I’m trying to reproduce this issue on my machine but without success yet. Are you able to paste the whole ACL block related to pasted kibana_hide_apps?
I tried to reproduce it by using these ACL blocks
- name: ADMIN_GRP
groups: [ Administrators ]
kibana_access: admin
kibana_hide_apps: [ "Security","Enterprise Search","Observability","Management","ROR Manage Kibana","ROR Security Settings"]
kibana_index: '.kibana_admins'
verbosity: error
- name: Infosec
groups: [ Infosec ]
kibana_access: rw
kibana_hide_apps: ["ROR Manage Kibana", "ROR Security Settings"]
verbosity: error
However, everything works as expected
@sscarduzio We actually have automatic tests for this part of the plugin 
