The idea of ACL-based queries is: each document carries all of the groups or roles that it is ok with. Each user search includes all of the groups or roles the user has.
The roles are stored as multivalued string fields. Each ACL-based query passes in "roles:A OR roles:B OR roles:C" and if any of A,B,C are in the stored ACL field, you have a match. This is called "early binding". "Late binding" is when you return everything and the app calls LDAP and say "can she see this? or this?". This is slow and puts a monster load on the ACL server. Very important: do not make a spelling or autosuggest index from a text field which some people can see and other people can't. On Tue, Oct 26, 2010 at 12:06 AM, Lance Norskog <goks...@gmail.com> wrote: > Filter queries are a set of bits which is ANDed against query results > at a very early stage of query processing. They are very useful. Note > that they are stored (I think) in parsed query order, so you have to > pass in the same filter query string each time. > > On Mon, Oct 25, 2010 at 8:59 AM, Dennis Gearon <gear...@sbcglobal.net> wrote: >> Thanks for that insight, a lot. >> >> Dennis Gearon >> >> Signature Warning >> ---------------- >> It is always a good idea to learn from your own mistakes. It is usually a >> better idea to learn from others’ mistakes, so you do not have to make them >> yourself. from >> 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' >> >> EARTH has a Right To Life, >> otherwise we all die. >> >> >> --- On Mon, 10/25/10, Jonathan Rochkind <rochk...@jhu.edu> wrote: >> >>> From: Jonathan Rochkind <rochk...@jhu.edu> >>> Subject: Re: Modelling Access Control >>> To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> >>> Date: Monday, October 25, 2010, 8:19 AM >>> Dennis Gearon wrote: >>> > why use filter queries? >>> > >>> > Wouldn't reducing the set headed into the filters by >>> putting it in the main query be faster? (A question to >>> learn, since I do NOT know :-) >>> > >>> > >>> No. At least as I understand it. In the best case, the >>> filter query will be a lot faster, because filter queries >>> are cached seperately in the filter cache. So if the >>> existing filter query can be found in the cache, it'll be a >>> lot faster. If it's not in the cache, the performance should >>> be pretty much the same as if you had included it as an >>> additional clause in the main q query. >>> >>> The reasons to put it in a fq filter are: >>> >>> 1) The caching behavior. You can have that certain part of >>> the query be cached on it's own, speeding up any subsequent >>> queries that use that same fq. >>> >>> 2) Simplification of client code. You can leave your 'q' >>> however you want it, using whatever kind of query parser you >>> want too (dismax, whatever), and just add on the 'fq' >>> without touching the 'q'. This is a lot >>> easier to do, and especially when you're using it for access >>> control like this, a lot harder for a bug to creep in. >>> >>> Jonathan >>> >>> >>> >> > > > > -- > Lance Norskog > goks...@gmail.com > -- Lance Norskog goks...@gmail.com
