[ 
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112360#comment-13112360
 ] 

Jan Høydahl commented on SOLR-1895:
-----------------------------------

Thanks Erik for explaining about Solr's post filter and DelegatingCollector. 
From JavaDoc: "This collector interface also enables better performance when an 
external system must be consulted, since document ids may be buffered and 
batched into a single request to the external system."

bq. Yikes! No, that's a nightmare with faceting and so on. You need to filter 
inline with the main query so that every component afterwards has the proper 
document set. Again, PostFilter was built for this very scenario.

Yes, late binding *is* expensive. That's why it's normally done only on top-N 
docs right before displaying, sacrificing 100% correct facet counts, but 
combining early and late binding makes this into a narrow corner case.

Does the DelegatingCollector require filtering of the full result set or can it 
do top-X? Consulting a Authority Service (MCF or other) for *all* IDs in the 
result set is sub-optimal, even if batched, and a high price to pay for exact 
facet counts.


> 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

Reply via email to