[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112673#comment-13112673
]
Karl Wright commented on SOLR-1895:
-----------------------------------
bq. I don't understand why you want/need to do that. The filters/queries are
all wrapped in a ConstantScoreQuery at the end - no need to convert the others.
I had intended to do some performance comparisons between filters and queries,
but I never got that far because of the problem I ran into and reported. I
thought that doing things in filterland might well be expensive when there are
lots of documents in the system, which is one thing I wanted to explore. That,
and also whether negated wildcards actually work reasonably or whether I should
be introducing a "nothing here" special token that would make the wildcard
queries unnecessary.
bq. Again, i think any discussion of QParser vs Component is irrelevant until
there is a general consensus that any security stuff belongs anywhere in solr.
After that, the question of QParser vs Component is more about where we want
this to go down the road...
Whatever the decision is, I still have a problem to solve and I'm working
towards solving it. Unless the Solr community decides that ManifoldCF's
intrinsic model is anathema, and fights any implementation tooth and nail, this
will still need to be done one way or another. Hope that's okay with you. In
the meantime I believe I've found a trunk bug that seems pretty serious. If I
get confirmation that I'm not just doing something stupid I'll open another
ticket for it, but all I'm looking for right at the moment is a simple, "yeah,
that should work", or "no, you idiot, you forgot xxx...."
> 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
