lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] Commented: (SOLR-2368) Improve extended dismax (edismax) parser
Date Fri, 18 Feb 2011 12:32:38 GMT


Jan Høydahl commented on SOLR-2368:

When I try to think practically on this, satisfying the vast majority of customers, locking
down stuff has been a customer requirement in perhaps 2-3 of the almost 100 enterprise installations
I've done over the last 11 years. The FAST search engine and its FQL query language by defaults
exposes all features and (internal) fields to the end user, and there is no way to lock it
down except through custom coding. If it's good enough for the largest enterprise customers
out there, I'm sure it's good enough for Solr users. If someone need more locking down, let
them contribute that - they won't sue anyone, this is collaboration :-)

This public news site runs Solr 1.4.2-dev with SOLR-1553:

Can anyone show a practical examples of queries end users can do here to crash/break the system
or security in any way? I can construct one:
in which the first clause triggers the known foo:bar bug but I cannot see any realistic worryable

Making edismax the default now (with an explicit way to switch to the old) and finalizing
baking in 3.2 before summer would be a win win, at least for those of my customers who are
planning to release on 3.1 in the coming months, all of them using edismax already.

> Improve extended dismax (edismax) parser
> ----------------------------------------
>                 Key: SOLR-2368
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Yonik Seeley
> Improve edismax and replace dismax once it has all of the needed features.

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message