Home | About | Sematext search-lucene.com search-hadoop.com
 Search Lucene and all its subprojects:

Switch to Threaded View
Solr, mail # user - Disable (or prohibit) per-field overrides


Copy link to this message
-
Re: Disable (or prohibit) per-field overrides
Markus Jelsma 2010-10-18, 15:05
Thanks for your reply. But as i replied the following to Erick's suggestion
which is quite the same:

>  Yes, we're using it but the problem is that there can be many fields
>  and that means quite a large list of parameters to set for each request
>  handler, and there can be many request handlers.
>  
>  It's not very practical for us to maintain such big set of invariants.

It's much easier for us to maintain a very short white list than a huge black
list.

Cheers

On Monday, October 18, 2010 04:59:09 pm Jonathan Rochkind wrote:
> You know about the 'invariant' that can be set in the request handler,
> right?  Not sure if that will do for you or not, but sounds related.
>
> Added recnetly to some wiki page somewhere although the feature has been
> there for a long time.  Let's see if I can find the wiki page...Ah yes:
>
> http://wiki.apache.org/solr/SearchHandler#Configuration
>
> Markus Jelsma wrote:
> > Hi,
> >
> > Thanks for the suggestion and pointer. We've implemented it using a
> > single regex in Nginx for now.
> >
> > Cheers,
> >
> >> : Anyone knows useful method to disable or prohibit the per-field
> >> : override features for the search components? If not, where to start
> >> : to make it configurable via solrconfig and attempt to come up with a
> >> : working patch?
> >>
> >> If your goal is to prevent *clients* from specifying these (while you're
> >> still allowed to use them in your defaults) then the simplest solution
> >> is probably something external to Solr -- along the lines of
> >> mod_rewrite.
> >>
> >> Internally...
> >>
> >> that would be tough.
> >>
> >> You could probably write a SearchComponent (configured to run "first")
> >> that does it fairly easily -- just wrap the SolrParams in an impl that
> >> retuns null anytime a component asks for a param name that starts with
> >> "f." (and excludes those param names when asked for a list of the param
> >> names)
> >>
> >>
> >> It could probably be generalized to support arbitrary rules i na way
> >> that might be handy for other folks, but it would still just be
> >> wrapping all of hte params, so it would prevent you from using them
> >> in your config as well.
> >>
> >> Ultimatley i think a general solution would need to be in
> >> RequestHandlerBase ... where it wraps the request params using the
> >> defaults and invariants ... you'd want the custom exclusion rules to
> >> apply only to the request params from the client.
> >>
> >>
> >>
> >>
> >> -Hoss

--
Markus Jelsma - CTO - Openindex
http://www.linkedin.com/in/markus17
050-8536600 / 06-50258350