On Tue, Aug 18, 2015 at 9:51 PM, Jamie Johnson <jej2...@gmail.com> wrote:
> Thanks, I'll try to delve into this. We are currently using the parent
> query parser, within we could use {!secure} I think. Ultimately I would
> want the solr qparser to actually do the work of parsing and I'd just wrap
> that.
Right... look at something like BoostQParserPlugin
it should be trivial to wrap any other type of query.
baseParser = subQuery(localParams.get(QueryParsing.V), null);
Query q = baseParser.getQuery();
q={!secure}my_normal_query
OR
q={!secure v=$qq)&qq=my_normal_query
OR
q={!secure}{!parent ...}
OR
q={!secure v=$qq}&qq={!parent. ..}
-Yonik
> Are there any examples that I could look at for this? It's not
> clear to me what to do in the qparser once I have the user auths though.
> Again thanks, this is really good stuff.
> On Aug 18, 2015 8:54 PM, "Yonik Seeley" <ysee...@gmail.com> wrote:
>
>> 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
>> >>
>>
