I wrote the following after hurriedly reading Grant Ingersoll's
question, and I completely missed the "to remove results that have
already been viewed" bit. Which leads me to think what I wrote may
have no bearing on this issue... but perhaps it may have bearing on
someone else's issue?
- J.J.
-----
Under the assumption that there is an untokenized field, say
UserAccess, with user names or IDs that for each document indicate
which users can access them...
If you could trust the requesting client to modify the request based
on the user name or ID, it could either
- Add an fq=UserAccess:userName argument to every request
- Create a RequestHandler configuration for each user, putting such
a fq (with a hardwired username) in an 'appends' section, along with
any other needed customization:
<requestHandler name="/users/tony" class="solr.StandardRequestHandler">
<lst name="appends">
<str name="fq">UserAccess:tony</str>
...
But if you cannot trust the requesting client and need to do the
filtering on the SOLR side of the divide, then I think you can simply
subclass and deploy org.apache.solr.servlet.SolrDispatchFilter, such
that in the execute() method you take the user (e.g. from
request.getRemoteUser() or some other means), format a fq argument as
above, and explicitly add it to the params in the SolrQueryRequest.
While users can add filters to their queries, they would not be able
to remove the applet-supplied filter query.
Regardless of how fq is specified, it would create a cached filter
for each user. Obviously the filter cache size should be greater than
the number of simultaneously active users plus the filters they use
in their queries; inactive users' filters will be scrubbed until the
next time.
-----
