On Tue, Aug 18, 2015 at 8:38 PM, Jamie Johnson <jej2...@gmail.com> wrote:
> I really like this idea in concept.  My query would literally be just a
> wrapper at that point, what would be the appropriate place to do this?

It depends on how much you are trying to make everything transparent
(that there is security) or not.

First approach is explicitly changing the query types (you obviously
need to make sure that only trusted code can run queries against solr
for this method):
q=foo:bar&fq=inStock:true
q={!secure id=user}foo:bar&fq={!secure id=user}inStock:true
  you could even make the {!secure} qparser look for global security
params so you don't need to repeat them.
q={!secure}foo:bar&fq={!secure}inStock:true&security_id=user

Second approach would prob involve a search component, probably that
runs after the query component, that would handle wrapping any queries
or filters in the prepare() phase.  This would be slightly more
difficult since it would require ensuring that none of the solr code /
features you use re-grab the "q" or "fq" parameters re-parse without
the opportunity for you to wrap them again.

> What would I need to do to the query to make it behave with the cache.

Probably not much... record the credentials in the wrapper and use in
the hashCode / equals.

-Yonik


> Again thanks for the idea, I think this could be a simple way to use the
> caches.
>
> On Tue, Aug 18, 2015 at 8:31 PM, Yonik Seeley <ysee...@gmail.com> wrote:
>
>> On Tue, Aug 18, 2015 at 8:19 PM, Jamie Johnson <jej2...@gmail.com> wrote:
>> > when you say a security filter, are you asking if I can express my
>> security
>> > constraint as a query?  If that is the case then the answer is no.  At
>> this
>> > point I have a requirement to secure Terms (a nightmare I know).
>>
>> Heh - ok, I figured as much.
>>
>> So... you could also wrap the main query and any filter queries in a
>> custom security query that would contain the user, and thus still be
>> able to use filter and query caches unmodified. I know... that's only
>> a small part of the problem though.
>>
>> -Yonik
>>

Reply via email to