Custom request handler/plugin

[javaxmlsoapdev <vi...@yahoo.com>]

I have a requirement to filter solr results, based on my application
entitlement rules,before they are returned from Solr to the application. In
order to do this, I have to implement a custom plugin, which gets entire
solr results and apply my application rules (which will be exposed via web
service from the app for solr to consume). This way reults will be
completely filtered from Solr itself before application gets response from
Solr. Currently my search uses DisMax. Now will need to use DisMax first and
then custom plugin to filter the results. What's the best way to implement.
FYI: I have gone thru SolrPlugin wiki page but need more info of how
chaining (if possible) for handlers can be used. e.g. First dixmax and then
custom plugin/handler. 

Please advise.

Thanks,

--
View this message in context: http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2673822.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Custom request handler/plugin

[javaxmlsoapdev <vi...@yahoo.com>]

Thanks for the response. Finally I have decided to build access intelligence
into the Solr to pre filter the results by storing required attributes in
the index to determine the access. 

--
View this message in context: http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2696319.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Custom request handler/plugin

["David Smiley (@MITRE.org)" <DS...@mitre.org>]

*If* you decide to check each result found in your search results against
some 3rd party so-called "entitlement service" which is essentially a black
box for this discussion, then your search results are going to be
disastrously slow; no?  Especially if it's a SOAP one ;-)  (I'm looking at
your userid)

You mentioned doing dynamic updates to the index and that you believed
adding the assignees to a quiz would somehow make these updates too slow. 
Why would it do that?

You mentioned wanting to avoid the need to have some background process to
know who is a super-admin (and perhaps other roles)?  What I suggest would
not require this.  Your index would contain role oriented security info,
though perhaps not super-admin since that's a catch-all.  At the start of a
request you lookup the roles of the user making the request, and then you
search taking into consideration those roles.  You needn't know the set of
all super-admins at any time, just wether the current request is one.

~ David Smiley

-----
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2675177.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Custom request handler/plugin

[javaxmlsoapdev <vi...@yahoo.com>]

Below are the reasons why I thought it wouldn't be feasible to have
pre-filtered results with filter queries. please comment.

Since can't pen down direct business reqs due to confidentially contact with
the client, I'll mock out scenario using an example.

- There is a parent entity called "Quiz", which has multiple "assignees".
Quiz has one-to-many with another entity called "Schools" and "School" has
multiple "Assessors". 

-There are two separate indexes 
1) for Quiz, Quiz title, details, status are the searchable attributes of
the Quiz and stored in the Quiz index.
2) School index. which has school name, and some other school related
searchable attributes in the index

now for e.g. when someone searches against Quiz title, search results will
be returned to the application. before displaying results following access
rules kick in from the application. they are nothing but java rules from the
application, which decide whether person can view a particular quiz document
(returned from Solr). 

-Rule first checks against an external entitlement service which has
authorization policy defining entitlement roles.  This external entitlement
service first returns "true" or "false" that whether person can "view"
"quiz" entity or not. 
      -If it returned false then that document is thrown out from the
resultset.
      -If it returned "true" then further check in the rule is; check
assignees of the quiz(from the database),       if person who logged in is
one of the assignees of that quiz document, which s/he is trying to view. If
yes then only s/he can view else not.
      -There is a super admin role in the entitlement service (again this is
external to our app). If logged in person is super admin then s/he can view
document. No need to check quiz assignments.

If I store quiz assignees into the index then on the fly update of a
document in the index would be too slow (yes we do update/insert index
documents on the fly when a new record is created or updated in the db).
Plus as I mentioned for super admin role there aren't any assignments. If I
decide to store super admins into the index, then it would mean there will
have to be some asynchronous thread running against entitlement service and
monitor this "super admin" role, everytime new person is added to that role,
add him to each indexed document's assignment list? 

The whole above thing looked too convoluted. Hence thought it would be clean
to leverage existing application logic (rules) and continue post processing.
That way pagination can work correctly if solr retruned resultset is also
filtered. If solr returned resultset isn't filtered then pagination won't
work correctly as application wouldn't know how many documents will be
kicked out (can't know how many "next" links to paint)

Sorry for the lengthy post but thought describing entire scenario would make
things clear from requirement and infrastructure point of view.

--
View this message in context: http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2674913.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Custom request handler/plugin

["David Smiley (@MITRE.org)" <DS...@mitre.org>]

Your approach is problematic.  It probably doesn't factor in things like
faceting, highlighting, ...
Can you say why it is that the original search can't include a filter query
to filter out results the user shouldn't have access to?  That's the
standard approach to implement access control.
~ David Smiley

-----
 Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2674267.html
Sent from the Solr - User mailing list archive at Nabble.com.