Hmm...so I think I have things setup correctly, I have a custom
QParserPlugin building a custom query that wraps the query built from the
base parser and stores the user who is executing the query. I've added the
username to the hashCode and equals checks so I think everything is setup
properly. I ran a quick test and it definitely looks like my items are
being cached now per user, which is really great.
The outage that I'm running into now is the FieldValueCache doesn't take
into account the query, so the FieldValueCache is built for user a and then
reused for user b, which is an issue for me. In short I'm back to my
NoOpCache for FieldValues. It's great that I'm in a better spot for the
others, but is there anything that can be done with FieldValues to take
into account the requesting user?
On Tue, Aug 18, 2015 at 9:59 PM, Yonik Seeley <ysee...@gmail.com> wrote:
> 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
> >> >>
> >>
>
