[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109507#comment-13109507
]
Erik Hatcher commented on SOLR-1895:
------------------------------------
bq. Both fq and SearchComponent would work for early binding, but when we want
to extend the model with an (optional) late binding, i.e. filtering search
results, fq won't cut it.
Not true. There's now PostFilter to enable late binding. This might even be
advantageous for this MCF filtering, as the WildcardQuery's could be expensive
filters to generate and work best on the most constrained subset matching the
rest of the traditional query and filters.
bq. A SearchComponent however can be extended not only to handle early+late
binding but also any other strange requirements there may be regarding
security, such as authentication by IP address, peeking at other parameters
A QParserPlugin can see all the parameters a SearchComponent can see
[createParser(String qstr, SolrParams localParams, SolrParams params,
SolrQueryRequest req)]
bq. ...else I think we'll start seeing a multitude of different ways to
integrate security which is not a competitive advantage for Solr
If we cannot elaborate those different ways at this point, then building a
"framework" is only asking for it to be changed later. In what scenarios would
a security filter want to modify the response?
bq. I don't see how to add code to merge/unify two (possibly 3rd party)
QParsers, except from creating a new umbrella one.
nested queries.
bq. We'll keep the "core" layer generic and thin. AccessTokenSecurityComponent
and AccessTokenService (which should perhaps be an Interface instead)
I'm not sure that those abstractions are general enough. I still think a
qparser is the simplest/cleanest thing that will work here and doesn't preclude
or make harder any future needs. All of these other abstractions mentioned
here are overkill, IMO, to what MCF needs - all it needs is a handful of
aggregated WildcardQuery's.
> 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
