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. 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
> >>
>
