And for hairy ACL processing, consider a post-filter. It's custom code that only evaluates a document _after_ it has made it through the primary query and any "lower cost" filters. See: http://yonik.com/advanced-filter-caching-in-solr/.
NOTE: this isn't the thing I would do first, it's much more efficient to implement some of the suggestions above. Any time you can trade off index-time work for query-time work, it's almost always better to do the work up-front during queries.... Best, Erick On Wed, Oct 19, 2016 at 12:07 PM, John Bickerstaff <j...@johnbickerstaff.com> wrote: > Thank you both! Very helpful. > > On Wed, Oct 19, 2016 at 8:48 AM, Shawn Heisey <apa...@elyograg.org> wrote: > >> On 10/18/2016 3:00 PM, John Bickerstaff wrote: >> > How (or is it even wise) to "segregate data" in Solr so that some data >> > can be seen by some users and some data not be seen? >> >> IMHO, security like this isn't really Solr's job ... but with the right >> data in the index, the system that DOES handle the security can include >> a filter with each user's query to restrict them to only the data they >> are allowed to see. There are many ways to put data in the index for >> efficient use by a filter. The simplest would be a boolean field with a >> name like isPublic or isPrivate, where true and false are mapped as >> necessary to public and private. >> >> Naturally, the users must not be able to reach Solr directly ... they >> must be restricted to the software that connects to Solr on their >> behalf. Blocking end users from direct network access to Solr is a good >> idea even if there are no other security needs. >> >> There are more comprehensive solutions available, as you will notice >> from other replies, but the idea of simple filtering, controlled by your >> application, should work. >> >> Thanks, >> Shawn >> >>
