Change to response - unauthenticated/unauthorized

Hi,

We recently updated ROR to latest version, and have noticed a minor issue/change in behaviour. I think you’ve already referred to it here:

Previously, the error message from an API call was pretty clear in case that the user was not correctly authenticated or didn’t have correct permissions:

{“error”:{“root_cause”:[{“reason”:“Forbidden by ReadonlyREST ES plugin”,“due_to”:[“OPERATION_NOT_ALLOWED”]}],“reason”:“Forbidden by ReadonlyREST ES plugin”,“due_to”:[“OPERATION_NOT_ALLOWED”],“status”:403}}

The new response in this situation - “index_not_found_exception”,“reason”:“no such index [myindex_ROR_q8uMU8q3tO]” etc. - is much less clear on what has happened, and has caused confusion with our developers.

Is there any current way to revert to the previous response, or any plans to address this in the future? Thanks!

  • Adrian

Do you think the confusion was generated by the change in behaviour or by the actual response? Because my understanding was that if you don’t have permissions to access something you shouldn’t expect to “see” it. :thinking:

If you are NOT using ROR pro/enterprise, alternate option is to upgrade to 1.19.x and enable prompt for basic auth (this is default behavior). This will result in a 403 error on API calls for unauthorized calls. If you are using ROR pro, recommended config is to disable the prompt. So enabling this will result in user prompt for Kibana users, when users try to run unauthorized command, which wont look good as they would already have logged in initially through proper prompt. So its a trade off that you need to choose, with current implementation.

1 Like

Hi,

It was more the content of response - it’s less clear that it’s a security problem so it can mean developers (who are not really aware of ROR) can spend longer trying to figure out whats wrong with their API calls. Not a big deal really!

Regards,

Adrian