[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109220#comment-13109220
]
Ryan McKinley commented on SOLR-1895:
-------------------------------------
bq. Can you give me an example of multiple filter queries being used?
Assume the user query was:
{code}
&q=hello&fq=type:big&fq={!dismax}hello world
{code}
and the handler had appends configured as:
{code}
<lst name="appends">
<str name="fq">{!mcf_security}</str>
</lst>
{code}
the handler would behave as if the input were actually:
{code}
&q=hello&fq=type:big&fq={!dismax}hello world&{!mcf_security}
{code}
The only hole i can point to is that i'm not sure what happens if it is
specified in both places. I'm also not 100% sure on the shard case
I'm confident a QParser would work, but i don't see any real advantage to it
over a SearchComponent. The purpose of a QueryParser is to *parse* the
query... but this does not require any parsing.
-----
I think the bigger question is do we want *any* security scaffolding in solr,
or is this something that should always be delegated elsewhere. If there is
strong resistance to including a general security model, we should make that
clear and not waste more time sorting out the details.
The core of this path is an allow/deny matrix to lucene Query; this is
applicable to many security strategies not just manifold. My hope with
introducing the AccessTokenService is to separate the user-to-token mapping
from how the lucene
> 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
