# Filtered alias and possible options for forcing filters for queries **URL:** \ **Category:** Elasticsearch\ **Created:** [January 31, 2014, 6:07pm UTC](https://discuss.elastic.co/t/filtered-alias-and-possible-options-for-forcing-filters-for-queries/15535 "2014-01-31T18:07:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Matthias\_Johnson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/matthias_johnson/32/1196_2.png) [@Matthias\_Johnson](https://discuss.elastic.co/u/Matthias_Johnson)\ **Post date:** [January 31, 2014, 6:07pm UTC](https://discuss.elastic.co/t/filtered-alias-and-possible-options-for-forcing-filters-for-queries/15535/1 "2014-01-31T18:07:02Z")
In our application we have the need to restrict access to data. We would like to use filters for that. The filtered alias[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html) seems like a nice way to do that and my original thought was to simply create an alias for each user and then add a filter to it as needed. That would work quite nicely, however we split the content potentially across many indices (think logstash and it's default per day index). Sadly a filter alias can only point to one index (wildcards don't seem to work in the 'index' either), which I assume is due to making it also work for document posting and updates .... With that said, is there something obvious I'm missing to get the desired functionality of applying/forcing a filter dependent on a user? Right now I'm considering 2 choices: 1. create per user aliases for each index they should have access to and then running the _search against /_\*/. That seems like it quickly becomes hard to scale and manage 2. store the user filters in ES and having a shim that inserts them at query time. Right now I already use a shim to authenticate via an HTTP header token through an nginx proxy Any thoughts and opinions would be most welcome. @matthias -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/9001455a-f75a-4161-b475-9d2d266369cc%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9001455a-f75a-4161-b475-9d2d266369cc%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\ **Post date:** [February 3, 2014, 10:47am UTC](https://discuss.elastic.co/t/filtered-alias-and-possible-options-for-forcing-filters-for-queries/15535/2 "2014-02-03T10:47:12Z")
Hi, I would go for option 1, it just means that while creating the alias, you need to provide a list of indices, and for each index you 'll need to provide a filter, which in your case will always be the same if I got it right. Does it make sense? On Friday, January 31, 2014 7:07:02 PM UTC+1, Matthias Johnson wrote: > In our application we have the need to restrict access to data. We would > like to use filters for that. The filtered alias[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html) seems > like a nice way to do that and my original thought was to simply create an > alias for each user and then add a filter to it as needed. > > That would work quite nicely, however we split the content potentially > across many indices (think logstash and it's default per day index). > > Sadly a filter alias can only point to one index (wildcards don't seem to > work in the 'index' either), which I assume is due to making it also work > for document posting and updates .... > > With that said, is there something obvious I'm missing to get the desired > functionality of applying/forcing a filter dependent on a user? > > Right now I'm considering 2 choices: > > 1. create per user aliases for each index they should have access to and > then running the _search against /_\*/. That seems like it quickly > becomes hard to scale and manage > > 2. store the user filters in ES and having a shim that inserts them at > query time. Right now I already use a shim to authenticate via an HTTP > header token through an nginx proxy > > Any thoughts and opinions would be most welcome. > > @matthias -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/93f636e7-882e-4261-92e1-fc13e8d0ff5c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/93f636e7-882e-4261-92e1-fc13e8d0ff5c%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Matthias\_Johnson](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/matthias_johnson/32/1196_2.png) [@Matthias\_Johnson](https://discuss.elastic.co/u/Matthias_Johnson)\ **Post date:** [February 3, 2014, 4:42pm UTC](https://discuss.elastic.co/t/filtered-alias-and-possible-options-for-forcing-filters-for-queries/15535/3 "2014-02-03T16:42:36Z")
It does, and that would leave me with only needing to solve the issue of a document update/load, since I won't be able to index against the alias with multiple indexes. For example: { "actions" : [ { "add" : { "index" : "doc\_1", "alias" : "test", "filter" : { "term" : { "\_all" : "world" } } } }, { "add" : { "index" : "doc\_2", "alias" : "test", "filter" : { "term" : { "\_all" : "world" } } } } ..... ] } If I end up creating a new index, I will need to update all user's aliases to add the new index. Although if it is missed, the worst case scenario will be "denied" access, rather than accidental leaking of data. That feels like a decent default. And for those with a filter I'll have to add it to each index line. It would be nice if the filter could be specified also globally for the alias. That will require some careful syncing, but should be reasonable. I will also need to solve the issue of possible updates to the alias and filter. I suspect that my auth layer can likely validate that the doc is accessibly via a HEAD request to the alias and if it shows up as visible I can permit the update to the actual index instead of the alias ... @matthias On Monday, February 3, 2014 3:47:12 AM UTC-7, Luca Cavanna wrote: > Hi, > I would go for option 1, it just means that while creating the alias, you > need to provide a list of indices, and for each index you 'll need to > provide a filter, which in your case will always be the same if I got it > right. > > Does it make sense? > > On Friday, January 31, 2014 7:07:02 PM UTC+1, Matthias Johnson wrote: > > > In our application we have the need to restrict access to data. We would > > like to use filters for that. The filtered alias[http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html) seems > > like a nice way to do that and my original thought was to simply create an > > alias for each user and then add a filter to it as needed. > > > > That would work quite nicely, however we split the content potentially > > across many indices (think logstash and it's default per day index). > > > > Sadly a filter alias can only point to one index (wildcards don't seem to > > work in the 'index' either), which I assume is due to making it also work > > for document posting and updates .... > > > > With that said, is there something obvious I'm missing to get the desired > > functionality of applying/forcing a filter dependent on a user? > > > > Right now I'm considering 2 choices: > > > > 1. create per user aliases for each index they should have access to and > > then running the _search against /_\*/. That seems like it quickly > > becomes hard to scale and manage > > > > 2. store the user filters in ES and having a shim that inserts them at > > query time. Right now I already use a shim to authenticate via an HTTP > > header token through an nginx proxy > > > > Any thoughts and opinions would be most welcome. > > > > @matthias -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/64454d01-f454-4ac3-8eff-9d1e984ea1b6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/64454d01-f454-4ac3-8eff-9d1e984ea1b6%40googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:53am UTC](https://discuss.elastic.co/t/filtered-alias-and-possible-options-for-forcing-filters-for-queries/15535/4 "2017-07-06T01:53:07Z")