Thanks Erick - also very helpful. On Wed, Oct 19, 2016 at 1:24 PM, Erick Erickson <[email protected]> wrote:
> 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 > <[email protected]> wrote: > > Thank you both! Very helpful. > > > > On Wed, Oct 19, 2016 at 8:48 AM, Shawn Heisey <[email protected]> > 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 > >> > >> >
