# Indices rule - Index not found scenario

Examples:

> Let's assume that our ES cluster has 2 indices: `index_a` and `index_b`. At the same time we have two users: `userA` and `userB`. We'd like to give `userA` access to index `index_a`, and `userB` to `index_b`. `userA` should not see or be even aware of `index_b` and vice versa. We'd like to give each of them a feeling that they are alone on the cluster.
>
> ROR `readonlyrest.yml` configuration may look like this:
>
> ```yaml
> readonlyrest:
>   enable: true
>   access_control_rules:
>
>      - name: "user A indices"
>        indices: ["index_a"]
>        auth_key: userA:secret
>
>      - name: "user B indices"
>        indices: ["indexB"]
>        auth_key: userB:secret
> ```
>
> We can test if `userA` is able to reach `index_a`:
>
> ```
> $ curl -v -u userA:secret "http://127.0.0.1:9200/index_a?pretty"
>   HTTP/1.1 200 OK
>   content-type: application/json; charset=UTF-8
>   content-length: 611
>    
>   {
>     "index_a" : {
>       "aliases" : { },
>       "mappings" : { ... }
>       "settings" : { ... }
>     }
>   }
> ```
>
> It looks like he is. So far, so good. Let's try to access nonexistent index (we know, that index with name `nonexistent` for sure doesn't exist on our cluster):
>
> ```
> $ curl -i -u userA:secret "http://127.0.0.1:9200/nonexistent?pretty"                                                                                             18:15:28
>   HTTP/1.1 404 Not Found
>   content-type: application/json; charset=UTF-8
>   content-length: 634
>
>   {
>     "error" : {
>       "root_cause" : [ ... ],
>       "type" : "index_not_found_exception",
>       "reason" : "no such index [nonexistent_ROR_ZA1FXDsR7M]",
>       "resource.type" : "index_or_alias",
>       "resource.id" : "nonexistent_ROR_ZA1FXDsR7M",
>       "index_uuid" : "_na_",
>       "index" : "nonexistent_ROR_ZA1FXDsR7M"
>     },
>     "status" : 404
>  }
> ```
>
> The response is pretty straight forward - the index doesn't exist. But, let's see what happens, when the same user, `userA`, will try to get `index_b`:
>
> ```
> $ curl -v -u userA:secret "http://127.0.0.1:9200/index_b?pretty"
>   HTTP/1.1 404 Not Found
>   content-type: application/json; charset=UTF-8
>   content-length: 610
>  
>   {
>     "error" : {
>       "root_cause" : [ ... ],
>       "type" : "index_not_found_exception",
>       "reason" : "no such index [index_b_ROR_QcskliAl8A]",
>       "resource.type" : "index_or_alias",
>       "resource.id" : "index_b_ROR_QcskliAl8A",
>       "index_uuid" : "_na_",
>       "index" : "index_b_ROR_QcskliAl8A"
>     },
>     "status" : 404
>   }
> ```
>
> As we can see `userA` is not able to get `index_b`. But the response is HTTP 404 Not Found - it means that the index doesn't exist.
>
> So, the response is the same as we get if the called index really doesn't exist. Thanks to the described behaviour, `userA` is not aware that on the cluster there are any other indices but the ones he was given access to.
>
> > note:
> >
> > Careful reader may notice that, in example above, `userA` was getting `index_b`, but the response says that there is no `index_b_ROR_QcskliAl8Aindex_b_ROR_QcskliAl8A` index. It's the trick ROR does to fool ES and be sure that asking index, which the user should not be allowed to see, won't be reached by him.
>
> But we should also consider the other case - using an index name with wildcard. So, `userA` will try to get all indices which names match `index*` pattern:
>
> ```
> $ curl -i -u userA:secret "http://127.0.0.1:9200/index*?pretty"                                                                                                  19:58:29
>   HTTP/1.1 200 OK
>   content-type: application/json; charset=UTF-8
>   content-length: 611
>   
>   {
>     "index_a" : {
>       "aliases" : { },
>       "mappings" : { ... },
>        "settings" : { ... }
>      }
>    }
> ```
>
> Response is exactly like we'd expect - only `index_a` was returned. But what if nothing matches our index name pattern?
>
> ```
> $ curl -i -u userA:secret "http://127.0.0.1:9200/index_userA*?pretty"                                                                                                20:05:10
>   HTTP/1.1 200 OK
>   content-type: application/json; charset=UTF-8
>   content-length: 4
>
>   { }
> ```
>
> Response is empty list. Now, let's see what happens when an index name pattern matches an index which is not authorized for a user who asks about it.
>
> ```
> $ curl -i -u userA:secret "http://127.0.0.1:9200/index_b*?pretty"                                                                                                20:14:34
>   HTTP/1.1 200 OK
>   content-type: application/json; charset=UTF-8
>   content-length: 4
>
>   { }
> ```
>
> As we see, response is the same as we have experienced when there was really no index matching the pattern. Also here a user has a feeling that only his indices are present on a cluster.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.readonlyrest.com/develop/elasticsearch/index-not-found-examples.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.