Thank you Timothy, With the indication you gave me (and the help of this article http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/ ) I managed to draft my own filter, but it seems that it doesn't work quite as I expected.
Here is what I've done so far: https://github.com/ColinHebert/Sakai-Solr/tree/permission/permission/solr/src/main/java/org/sakaiproject/search/solr/permission/filter But it seems that the filter is applied on every document matched by a query (rather than doing that on the range of documents I searched for). I've done some tests with 10k+ documents and the query /select?q=*%3A*&fq={!sakai%20userId=admin}&tv=false&start=0&rows=1 takes ages to execute (and in my application I can see that solr is trying to apply the filter on absolutely every document. Cheers, Colin Colin Hebert On 26 February 2013 15:30, Timothy Potter <thelabd...@gmail.com> wrote: > Hi Colin, > > I think a filter is definitely the way to go. Moreover, you should > look into Solr's PostFilter concept which is intended to work with > "expensive" filters. Have a look at Yonik's blog post on this topic: > http://yonik.com/posts/advanced-filter-caching-in-solr/ > > Cheers, > Tim > > On Tue, Feb 26, 2013 at 7:24 AM, Colin Hebert <hebert.co...@gmail.com> wrote: >> Hi, >> >> I have some troubles to figure out the right thing when it comes to >> filtering results for security reasons. >> >> I work on this application that contains documents that are not >> accessible to everyone, so I want to filter the search results, based >> on the right to read each document for the user making the search >> query. >> To do that, right now, I have a filter on the application side that >> checks for each document returned by a search query, if it is >> accessible by the current user, and removes it from the result list if >> it isn't. >> >> That isn't really optimal as you might get a result page with 7 >> results instead of 10 because some results were removed (and if you're >> smart enough you can figure out the content of those hidden documents >> by doing many search queries). >> >> So I can think of two solutions, either I code a paging system in my >> application that will take care of those holes in the result list, but >> it adds quite a lot of work that could be useless if solr can take >> care of that. >> The second solution is having solr filtering those results before >> sending them back. >> >> The second solution seems a bit more clean to me, but I'm not sure if >> it is a good practice or not. >> >> The permission system in the application is a bit 'wild', some >> permissions are based on the day of the week, others on the existence >> or not of another document, so I can't really get out of this >> situation by storing more information in the index and using standard >> filters. >> If creating a custom filter in Solr isn't too bad, what I was thinking >> of would require the solr server making a request to the application >> to check if the user (given as a parameter in the query) can access >> the document (and that should be done on each document). >> Note that I will have to do that security check anyways, so the time >> to do a security check isn't (at least shouldn't) be relevant to the >> performances of a solution over the other. >> What will have an impact though is the fact that the solr server has >> to do a request to the application (network connection) for each >> document. >> >> Colin Hebert
