Well, there are about 17 ways to do this. OK, I'm exaggerating...... WordDelimiterFilterFactory in a text field (with the appropriate parameters set) will do what you want. Basically it'll index Apache Tomcat (7|0|0|x|whatever) where the tokens indexed are split by any non-alphanumeric in the same position. Now, searching on "Apache Tomcat 7" (as a phrase) will find the documents.
There are about a zillion filters that you can specify in your field definition that will do an amazing number of things, here's a partial list: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters The admin/analysis page is definitely your friend when it comes to figuring out the interactions between all these filters. Best, Erick On Wed, May 25, 2016 at 8:21 PM, Jay Potharaju <jspothar...@gmail.com> wrote: > You can use the text_en/text_general field type to query those fields. Use > the analysis tab to see how querying works. > > > On Wed, May 25, 2016 at 8:16 PM, Carl Roberts <carl.roberts.zap...@gmail.com >> wrote: > >> Hi, >> >> Sorry to ask this question again but I had some recent issues with SPAM >> filtering so I don't know if someone responded before or not. >> >> Basically I am looking for a way to query a field for a substring in it >> with functionality similar to what Java String.contains would return: >> >> So for example, If I have these 2 summary field values: >> >> "summary": "Apache Tomcat 7.x before 7.0.10 does not follow >> : > ServletSecurity annotations, which allows remote attackers to bypass >> : > intended access >> : > restrictions via HTTP requests to a web application.", >> : > >> "summary": "Apache Tomcat 7.0.0 through 7.0.6 and 6.0.0 through >> : > 6.0.30 does not enforce the maxHttpHeaderSize limit for requests >> involving >> : > the NIO HTTP connector, which allows remote attackers to cause a >> denial of >> : > service (OutOfMemoryError) via a crafted request.", >> >> I want to be able to provide a query that states, give me all records that >> have a field summary that contain "Apache Tomcat 7" so that both fields >> above are returned. >> >> Is there a way to do that? >> >> Regards, >> >> Joe >> >> On 5/23/16 12:37 PM, Chris Hostetter wrote: >> >>> The mailing list you are looking for is "solr-user@lucene.apache.org" >>> >>> solr-user-info is an automated bot for giving you info about the list >>> solr-user-owner is for contacting the human moderators of the mailing list >>> with help >>> >>> >>> >>> >>> : Date: Sat, 21 May 2016 09:07:00 -0400 >>> : From: Carl Roberts <carl.roberts.zap...@gmail.com> >>> : To: solr-user-i...@lucene.apache.org, solr-user-ow...@lucene.apache.org >>> : Subject: Re: How to properly query indexed Data >>> : >>> : What is a reasonable time to expect an answer to questions in this user >>> list? >>> : >>> : On 5/18/16 8:55 PM, Carl Roberts wrote: >>> : > Hi, >>> : > >>> : > I am using Solar 4.10.3 and I the default URL for the GUI that comes >>> with >>> : > Solar: >>> : > >>> : > This is the URL: http://10.1.161.23:8983/solr/#/nvd-rss/query >>> : > >>> : > I have the following entries with field summary that are indexed. >>> : > >>> : > If I search for summary:"Apache Tomcat 7" I only get 10 results and >>> the ones >>> : > with Apache Tomcat 7.0.0 in the summary are missing from the results. >>> : > >>> : > If I search for summary:"Apache Tomcat 7.0.0" I only get the 3 with >>> the >>> : > "Apache Tomcat 7.0.0 in the summary. >>> : > >>> : > How do I get all of them? What filter should I use? I guess I am >>> looking >>> : > for a filter that says this: >>> : > >>> : > Give me all Entries that start with "Apache Tomcat 7" where 7 can be >>> : > followed by 0.0 as in 7.0.0 or it can be followed by x as in 7.x or >>> anything >>> : > else. >>> : > >>> : > How do I do that? >>> : > >>> : > ~/dev/temp$ grep "Apache Tomcat 7" apache-tomcat-query.txt >>> : > >>> : > "summary": "Apache Tomcat 7.x before 7.0.10 does not follow >>> : > ServletSecurity annotations, which allows remote attackers to bypass >>> : > intended access >>> : > restrictions via HTTP requests to a web application.", >>> : > >>> : > "summary": "Apache Tomcat 7.0.0 through 7.0.6 and 6.0.0 >>> through >>> : > 6.0.30 does not enforce the maxHttpHeaderSize limit for requests >>> involving >>> : > the NIO HTTP connector, which allows remote attackers to cause a >>> denial of >>> : > service (OutOfMemoryError) via a crafted request.", >>> : > >>> : > "summary": >>> "org/apache/catalina/core/DefaultInstanceManager.java in >>> : > Apache Tomcat 7.x before 7.0.22 does not properly restrict >>> ContainerServlets >>> : > in the Manager application, which allows local users to gain >>> privileges by >>> : > using an untrusted web application to access the Manager application's >>> : > functionality.", >>> : > >>> : > "summary": "Unrestricted file upload vulnerability in Apache >>> Tomcat >>> : > 7.x before 7.0.40, in certain situations involving outdated >>> java.io.File >>> : > code and a custom JMX configuration, allows remote attackers to >>> execute >>> : > arbitrary code by uploading and accessing a JSP file.", >>> : > >>> : > "summary": "A certain tomcat7 package for Apache Tomcat 7 in >>> Red Hat >>> : > Enterprise Linux (RHEL) 7 allows remote attackers to cause a denial of >>> : > service (CPU consumption) via a crafted request. NOTE: this >>> vulnerability >>> : > exists because of an unspecified regression.", >>> : > >>> : > "summary": "Apache Tomcat 7.0.0 through 7.0.3, 6.0.x, and >>> 5.5.x, >>> : > when running within a SecurityManager, does not make the >>> ServletContext >>> : > attribute read-only, which allows local web applications to read or >>> write >>> : > files outside of the intended working directory, as demonstrated >>> using a >>> : > directory traversal attack.", >>> : > >>> : > "summary": "Apache Tomcat 7.0.11, when web.xml has no login >>> : > configuration, does not follow security constraints, which allows >>> remote >>> : > attackers to bypass intended access restrictions via HTTP requests to >>> a >>> : > meta-data complete web application. NOTE: this vulnerability exists >>> because >>> : > of an incorrect fix for CVE-2011-1088 and CVE-2011-1419.", >>> : > >>> : > "summary": "Apache Tomcat 7.x before 7.0.11, when web.xml has >>> no >>> : > security constraints, does not follow ServletSecurity annotations, >>> which >>> : > allows remote attackers to bypass intended access restrictions via >>> HTTP >>> : > requests to a web application. NOTE: this vulnerability exists >>> because of >>> : > an incomplete fix for CVE-2011-1088.", >>> : > >>> : > "summary": "The HTTP BIO connector in Apache Tomcat 7.0.x >>> before >>> : > 7.0.12 does not properly handle HTTP pipelining, which allows remote >>> : > attackers to read responses intended for other clients in >>> opportunistic >>> : > circumstances by examining the application data in HTTP packets, >>> related to >>> : > \"a mix-up of responses for requests from different users.\"", >>> : > >>> : > "summary": "Apache Tomcat 7.0.12 and 7.0.13 processes the >>> first >>> : > request to a servlet without following security constraints that have >>> been >>> : > configured through annotations, which allows remote attackers to >>> bypass >>> : > intended access restrictions via HTTP requests. NOTE: this >>> vulnerability >>> : > exists because of an incomplete fix for CVE-2011-1088, CVE-2011-1183, >>> and >>> : > CVE-2011-1419.", >>> : > >>> : > "summary": "Apache Tomcat 7.0.x before 7.0.17 permits web >>> : > applications to replace an XML parser used for other web >>> applications, which >>> : > allows local users to read or modify the (1) web.xml, (2) >>> context.xml, or >>> : > (3) tld files of arbitrary web applications via a crafted application >>> that >>> : > is loaded earlier than the target application. NOTE: this >>> vulnerability >>> : > exists because of a CVE-2009-0783 regression.", >>> : > >>> : > "summary": "Certain AJP protocol connector implementations in >>> Apache >>> : > Tomcat 7.0.0 through 7.0.20, 6.0.0 through 6.0.33, 5.5.0 through >>> 5.5.33, and >>> : > possibly other versions allow remote attackers to spoof AJP requests, >>> bypass >>> : > authentication, and obtain sensitive information by causing the >>> connector to >>> : > interpret a request body as a new request.", >>> : > >>> : > "summary": "** DISPUTED ** Apache Tomcat 7.x uses >>> world-readable >>> : > permissions for the log directory and its files, which might allow >>> local >>> : > users to obtain sensitive information by reading a file. NOTE: One >>> Tomcat >>> : > distributor has stated \"The tomcat log directory does not contain any >>> : > sensitive information.\"", >>> : > >>> : > "summary": >>> "java/org/apache/catalina/core/AsyncContextImpl.java in >>> : > Apache Tomcat 7.x before 7.0.40 does not properly handle the throwing >>> of a >>> : > RuntimeException in an AsyncListener in an application, which allows >>> : > context-dependent attackers to obtain sensitive request information >>> intended >>> : > for other applications in opportunistic circumstances via an >>> application >>> : > that records the requests that it processes.", >>> : > >>> : > "summary": "Session fixation vulnerability in Apache Tomcat >>> 7.x >>> : > before 7.0.66, 8.x before 8.0.30, and 9.x before 9.0.0.M2, when >>> different >>> : > session settings are used for deployments of multiple versions of the >>> same >>> : > web application, might allow remote attackers to hijack web sessions >>> by >>> : > leveraging use of a requestedSessionSSL field for an unintended >>> request, >>> : > related to CoyoteAdapter.java and Request.java.", >>> : > >>> : > "summary": "The (1) Manager and (2) Host Manager applications >>> in >>> : > Apache Tomcat 7.x before 7.0.68, 8.x before 8.0.31, and 9.x before >>> 9.0.0.M2 >>> : > establish sessions and send CSRF tokens for arbitrary new requests, >>> which >>> : > allows remote attackers to bypass a CSRF protection mechanism by >>> using a >>> : > token.", >>> : > >>> : > "summary": "The setGlobalContext method in >>> : > org/apache/naming/factory/ResourceLinkFactory.java in Apache Tomcat >>> 7.x >>> : > before 7.0.68, 8.x before 8.0.31, and 9.x before 9.0.0.M3 does not >>> consider >>> : > whether ResourceLinkFactory.setGlobalContext callers are authorized, >>> which >>> : > allows remote authenticated users to bypass intended SecurityManager >>> : > restrictions and read or write to arbitrary application data, or >>> cause a >>> : > denial of service (application disruption), via a web application >>> that sets >>> : > a crafted global context.", >>> : >>> : >>> >>> -Hoss >>> http://www.lucidworks.com/ >>> >> >> > > > -- > Thanks > Jay Potharaju
