[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109155#comment-13109155
]
Erik Hatcher commented on SOLR-1895:
------------------------------------
bq. Any reason this can't just be a custom QParserPlugin?
ummm, duh! yes, that's the way to do it, IMO. I should have thought of that
right off the bat, but I got blinded by the existing patch and was just keying
off how it was implemented as a SearchComponent.
bq. Are there any conceivable cases where there might be a filter query in
place already? In those cases is there facility for handling more than one
filter query parser at a time?
I don't understand... any number of filter queries can be specified, each using
their own unique query parser, taking their own (local) parameters as
necessary, or leveraging global ones if that makes sense, or using globals that
are overridden by locals.
So I think this boils down to MCF having a custom query parser in it's codebase
(yes, it'll have to depend on Solr, but it already does in terms of being able
to index into Solr).
And, there is already a mechanism to bake that type of filtering into any
request handler so the client isn't necessarily responsible for setting it -
using the an "appends" section in the request handler definition to specify
something like this:
{code}
<lst name="appends">
<str name="fq">{!mcf_security ... [optional local params]}[...
optional "q" ...]</str>
</lst>
{code}
Any holes in doing it this way? Seems the cleanest/slickest way to me
currently.
> ManifoldCF SearchComponent plugin for enforcing ManifoldCF security at search
> time
> ----------------------------------------------------------------------------------
>
> Key: SOLR-1895
> URL: https://issues.apache.org/jira/browse/SOLR-1895
> Project: Solr
> Issue Type: New Feature
> Components: SearchComponents - other
> Reporter: Karl Wright
> Labels: document, security, solr
> Fix For: 3.5, 4.0
>
> Attachments: LCFSecurityFilter.java, LCFSecurityFilter.java,
> LCFSecurityFilter.java, LCFSecurityFilter.java,
> SOLR-1895-service-plugin.patch, SOLR-1895-service-plugin.patch,
> SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch, SOLR-1895.patch,
> SOLR-1895.patch, SOLR-1895.patch
>
>
> I've written an LCF SearchComponent which filters returned results based on
> access tokens provided by LCF's authority service. The component requires
> you to configure the appropriate authority service URL base, e.g.:
> <!-- LCF document security enforcement component -->
> <searchComponent name="lcfSecurity" class="LCFSecurityFilter">
> <str
> name="AuthorityServiceBaseURL">http://localhost:8080/lcf-authority-service</str>
> </searchComponent>
> Also required are the following schema.xml additions:
> <!-- Security fields -->
> <field name="allow_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_document" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="allow_token_share" type="string" indexed="true"
> stored="false" multiValued="true"/>
> <field name="deny_token_share" type="string" indexed="true" stored="false"
> multiValued="true"/>
> Finally, to tie it into the standard request handler, it seems to need to run
> last:
> <requestHandler name="standard" class="solr.SearchHandler" default="true">
> <arr name="last-components">
> <str>lcfSecurity</str>
> </arr>
> ...
> I have not set a package for this code. Nor have I been able to get it
> reviewed by someone as conversant with Solr as I would prefer. It is my
> hope, however, that this module will become part of the standard Solr 1.5
> suite of search components, since that would tie it in with LCF nicely.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
