Delete / filter / hide query results

[DODMax <m....@e-deal.com>]

Hello,

I'm trying to resolve a problem for which I've seen several posts but I have
not found any suitable answer.

I need to filter my results according to complex rights managment such as it
can't be part of a field or something like this. So let's say that the only
way to know if a user has access rights is by calling something like
accessRights(sessionID, docID) where docID is stored in a field.

My first idea was to simply delete results from rsp.getResults() after the
search process but it breaks faceting (expecially facet count). So since I
don't see any way to delete results from faceting it's not a good answer
(anyway it's ugly to build facets to delete them after).

I then decided to use a custom SearchComponent called right after index
querying (before faceting is done) but for what I have read it's not a good
idea to delete results because they are stored in more than one place and it
could break the caching system (I suppose that if I delete results for user
A they will be deleted for user B too if he makes the same query although he
does have access rights). Anyway I don't really understand where results are
stored in ResponseBuilder; DocSet / DocList are pretty obscur.

So here I am, I need a way to filter results from cache for each query
basing on an external function call but I don't see how without having to
write my own QueryComponent).


Thanks for your help.
-- 
View this message in context: http://www.nabble.com/Delete---filter---hide-query-results-tp21287332p21287332.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Delete / filter / hide query results

[Chris Hostetter <ho...@fucit.org>]

: can't be part of a field or something like this. So let's say that the only
: way to know if a user has access rights is by calling something like
: accessRights(sessionID, docID) where docID is stored in a field.

first tip: 'stored' valuves are going to be really inefficient to deal 
with on every request, at a bare minimum make sure this field is indexed 
and make all of your custom code access it using the FieldCache.

: I then decided to use a custom SearchComponent called right after index
: querying (before faceting is done) but for what I have read it's not a good
: idea to delete results because they are stored in more than one place and it
: could break the caching system (I suppose that if I delete results for user
: A they will be deleted for user B too if he makes the same query although he
: does have access rights). Anyway I don't really understand where results are
: stored in ResponseBuilder; DocSet / DocList are pretty obscur.

A DocSet is an unordered set of documents -- in the context of a query 
it's the set of all documents matching that query.  A DocList is an 
ordered (sub-)list of documents with some metadata about the whole list -- 
in the context of a query it's the "page" of documents being returned ot 
the user; ie: docs 11-20 of 5478.  (this is all pretty well mentioned in 
the docs)

if you want to modify the DocList/DocSet included in query response, it's 
fairly easy to do -- the key is just that you shouldn't modify the 
existing DocSet/DocList objects becuase they are probably stored in the 
cache, but you are free to construct new instances and replace the ones in 
the response ... the FacetComponent will use your replacement DocSet when 
it comes.

note that applying your access control to the DocSet will be easy, because 
it's a complete set of unordered docs, you can remove anyting you want.  
but the DocList has a lot more itneresting use cases to worry about.   if 
the DocList is 11-20 or 5478 total matches, and you wnat to remove 2 you 
have to go search for what the next 2 would be to make sure you still 
return 10.  but you also have to worry about wether the orriginal 11-20 
that the QueryComponent generated were right in the first place.  when the 
user made his first request for 1-10, your security component might have 
pulled out 3, but the QueryComponent didn't know that when it picked 
11-20, so you are already off by 3 from where you should be.

this is why post-processing access control tends to be a bad idea (beyond 
just extra goodies like faceting) ... things get a lot cleaner if you 
ensure your access controls get applied at query time.

you should cosider implementing your access controls as a new type of 
query and using it as a filter ... with the new ValueSource parser hooks 
you could implement your logic as a "function" that takes a sessionId as 
input and reuse all of the existing query code.


-Hoss

Re: Delete / filter / hide query results

[DODMax <m....@e-deal.com>]

Please I really need some help to solve this.
Does anybody have even a little idea ?

Thank you.

-- 
View this message in context: http://www.nabble.com/Delete---filter---hide-query-results-tp21287332p21326944.html
Sent from the Solr - User mailing list archive at Nabble.com.