Pushing ACL logic outside Solr sounds like a prudent choice indeed as in, my opinion, all of the business rules/conceptual logic should reside only within the code boundaries. This way your domain will be easier to model and your code to read, understand and maintain.
More information on Filter Queries, when they should be used and how they affect performance can be found here: http://wiki.apache.org/solr/FilterQueryGuidance On 23 October 2010 20:00, Dennis Gearon <gear...@sbcglobal.net> wrote: > Forgot to add, > 3/ The external, application code selects the GROUPS that the user has > permission to read (Solr will only serve up what is to be read?) then search > on those groups. > > > 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 Sat, 10/23/10, Dennis Gearon <gear...@sbcglobal.net> wrote: > > > From: Dennis Gearon <gear...@sbcglobal.net> > > Subject: Re: Modelling Access Control > > To: solr-user@lucene.apache.org > > Date: Saturday, October 23, 2010, 11:49 AM > > Two things will lessen the solr > > admininstrative load : > > > > 1/ Follow examples of databases and *nix OSs. Give each > > user their own group, or set up groups that don't have > > regular users as OWNERS, but can have users assigned to the > > group to give them particular permissions. I.E. Roles, like > > publishers, reviewers, friends, etc. > > > > 2/ Put your ACL outside of Solr, using your > > server-side/command line language's object oriented > > properties. Force all searches to come from a single > > location in code (not sure how to do that), and make the > > piece of code check authentication and authorization. > > > > This is what my research shows how others do it, and how I > > plan to do it. ANY insight others have on this, I really > > want to hear. > > > > 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 Sat, 10/23/10, Paul Carey <paul.p.ca...@gmail.com> > > wrote: > > > > > From: Paul Carey <paul.p.ca...@gmail.com> > > > Subject: Modelling Access Control > > > To: solr-user@lucene.apache.org > > > Date: Saturday, October 23, 2010, 1:03 AM > > > Hi > > > > > > My domain model is made of users that have access to > > > projects which > > > are composed of items. I'm hoping to use Solr and > > would > > > like to make > > > sure that searches only return results for items that > > users > > > have > > > access to. > > > > > > I've looked over some of the older posts on this > > mailing > > > list about > > > access control and saw a suggestion along the lines > > of > > > acl:<user_id> AND (actual query). > > > > > > While this obviously works, there are a couple of > > niggles. > > > Every item > > > must have a list of valid user ids (typically less > > than 100 > > > in my > > > case). Every time a collaborator is added to or > > removed > > > from a > > > project, I need to update every item in that project. > > This > > > will > > > typically be fewer than 1000 items, so I guess is no > > big > > > deal. > > > > > > I wondered if the following might be a reasonable > > > alternative, > > > assuming the number of projects to which a user has > > access > > > is lower > > > than a certain bound. > > > (acl:<project_id> OR acl:<project_id> OR > > ... ) > > > AND (actual query) > > > > > > When the numbers are small - e.g. each user has access > > to > > > ~20 projects > > > and each project has ~20 collaborators - is one > > approach > > > preferable > > > over another? And when outliers exist - e.g. a project > > with > > > 2000 > > > collaborators, or a user with access to 2000 projects > > - is > > > one > > > approach more liable to fail than the other? > > > > > > Many thanks > > > > > > Paul > > > > > >
