[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280064#comment-17280064
 ] 

Isabelle Giguere commented on SOLR-7913:


Patch on release tag lucene-solr 8.7.0: SOLR-7913_tag_lucene-solr-8.7.0.patch
Improvement : this patch does not ignore 
org.apache.solr.request.TestRemoteStreaming.testNoUrlAccess()
The modifications in RequestUtils are aimed exclusively at MTLQParser, nothing 
else should be affected.

This patch re-introduces the changes in SearchHandler and ShardRequest that 
were present in previous patches (Solr 5, 6, 7).  These changes allow passing 
the POST body to the MLTQParser.  My analysis on Solr 8.5.0 may have been 
completely wrong .. or there may have been another issue ?  I would need to 
double-check, if I make the time.

In unit test, results are surprisingly similar in SimpleMLTQParserTest, when 
comparing the tests with id and with stream.body
Results are different with id and with stream.body in CloudMLTQParserTest ... 
possibly because of merging results from shards.

Remaining issue : searching on an alias returns no results.  No idea why.

I would also have to make the time to re-create the same patch on Solr master.



> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch, SOLR-7913_tag_lucene-solr-8.7.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913_tag_lucene-solr-8.7.0.patch

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch, SOLR-7913_tag_lucene-solr-8.7.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-5480) Make MoreLikeThisHandler distributable

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277522#comment-17277522
 ] 

Isabelle Giguere commented on SOLR-5480:


[~erickerickson], [~noble.paul], [~anshum], [~hossman]
Before we deprecate the MLT Handler, can we please have some sort of valid 
solution for passing in text to the MLT QParser ?  To support uses cases where 
the id of the initial document is not known.

https://issues.apache.org/jira/browse/SOLR-7913?focusedCommentId=17267477=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17267477

The main purpose of SOLR-7913 is to pass plain text to MLT QParser.  It 
concentrates on stream.body, because, at one time, it looked like the best way 
to do so.
But if text could be passed to MLT QParser in any other way, there would be no 
reason to insist on using stream.body.


> Make MoreLikeThisHandler distributable
> --
>
> Key: SOLR-5480
> URL: https://issues.apache.org/jira/browse/SOLR-5480
> Project: Solr
>  Issue Type: Improvement
>  Components: MoreLikeThis
>Reporter: Steve Molloy
>Assignee: Noble Paul
>Priority: Major
> Attachments: MoreLikeThisHandlerTestST.txt, SOLR-5480.patch, 
> SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, 
> SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, SOLR-5480.patch, 
> SOLR-5480.patch, SOLR-5480.patch
>
>
> The MoreLikeThis component, when used in the standard search handler supports 
> distributed searches. But the MoreLikeThisHandler itself doesn't, which 
> prevents from say, passing in text to perform the query. I'll start looking 
> into adapting the SearchHandler logic to the MoreLikeThisHandler. If anyone 
> has some work done already and want to share, or want to contribute, any help 
> will be welcomed. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277272#comment-17277272
 ] 

Isabelle Giguere commented on SOLR-14886:
-

Patch off current Solr master branch (9.x)

- Add a property "hideStackTrace" to solr.xml
- In NodeConfig, the default value is "false", for back-compatibility.
- Use the new property in ResponseUtils, to print out, or not, the stack trace.
- Adapt code that calls ResponseUtils
- Add documentation in Ref Guide

There's no direct path between solr.xml and ResponseUtils, or any class that 
uses ResponseUtils, so the "hideStackTrace" property is duplicated in 
CoreContainer, just so it lives in a place where it can be read. May not be the 
best approach.

Note that the patch cannot fix the cases where the error message ()contains the full stack trace.

> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
> Attachments: SOLR-14886.patch, SOLR-14886.patch
>
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14886:

Attachment: SOLR-14886.patch

> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
> Attachments: SOLR-14886.patch, SOLR-14886.patch
>
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8393) Component for Solr resource usage planning

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276715#comment-17276715
 ] 

Isabelle Giguere commented on SOLR-8393:


New patch, off current master

Parameter 'sizeUnit' is supported for both the SizeComponent, and ClusterSizing.

If parameter 'sizeUnit' is present, values will be output as 'double', 
according to the chosen size unit.
Value of 'estimated-num-docs' remains a 'long'.
Default behavior, if 'sizeUnit' is not present is the human-readable format.

Valid values for 'sizeUnit' are : GB, MB, KB, bytes

**
Note about the implementation : 
ClusterSizing calls the SizeComponent via HTTP.  So the returned results per 
collection are already formatted according to 'sizeUnit' (or lack of it).  As a 
consequence, ClusterSizing needs to toggle back and forth between 
human-readable values, and raw long values, to support the requested 'sizeUnit'.
I don't know how we could intercept the SizeComponent response, and receive 
just the long values, to make the conversion to some 'sizeUnit' just once in 
ClusterSizing, while keeping the formatting in SizeComponent, for use cases 
that would call it directly.
A response transformer ?  Would that be the right approach ?

> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run 
> Solr. The most common response is that it highly depends on your data. While 
> true, it makes for frustrated users trying to plan their deployments. 
> The idea I'm bringing is to create a new component that will attempt to 
> extrapolate resources needed in the future by looking at resources currently 
> used. By adding a parameter for the target number of documents, current 
> resources are adapted by a ratio relative to current number of documents.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8393) Component for Solr resource usage planning

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8393:
---
Attachment: SOLR-8393.patch

> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run 
> Solr. The most common response is that it highly depends on your data. While 
> true, it makes for frustrated users trying to plan their deployments. 
> The idea I'm bringing is to create a new component that will attempt to 
> extrapolate resources needed in the future by looking at resources currently 
> used. By adding a parameter for the target number of documents, current 
> resources are adapted by a ratio relative to current number of documents.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13209) NullPointerException from call in org.apache.solr.search.SolrIndexSearcher.getDocSet

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276644#comment-17276644
 ] 

Isabelle Giguere commented on SOLR-13209:
-

[~cader.hancock] : Nothing to worry about.  I get lost in Solr every time I get 
back to it.

Grouping.java looks like a good place to start.  It seems the request from the 
description can go through the execute() method without error.  Maybe that's 
wanted.  But if Grouping.CommandQuery expects to work with a valid "query", 
then I think Grouping.CommandQuery.prepare() should throw an exception if 
"query" is null ?

That's just from looking at the code, so, it needs testing.

> NullPointerException from call in 
> org.apache.solr.search.SolrIndexSearcher.getDocSet
> 
>
> Key: SOLR-13209
> URL: https://issues.apache.org/jira/browse/SOLR-13209
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will 
> allow you to reproduce the issue reported.
>Reporter: Cesar Rodriguez
>Priority: Minor
>  Labels: diffblue, newdev
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?group=true
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
>   at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:124)
>   at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:163)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:792)
>   at 
> org.apache.solr.search.Grouping$CommandQuery.createFirstPassCollector(Grouping.java:860)
>   at org.apache.solr.search.Grouping.execute(Grouping.java:327)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessGroupedSearch(QueryComponent.java:1408)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:365)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> [...]
> {noformat}
> Method {{org.apache.solr.search.SolrIndexSearcher.getDocSet()}}, at line 792 
> calls {{filterCache.get(absQ)}} where {{absQ}} is a null pointer. I think 
> this null pointer comes in fact from the caller, but I don't fully follow the 
> logic of the code.
> To set up an environment to reproduce this bug, follow the description in the 
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue 
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. 
> Find more information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



--
This message was sent by Atlassian 

[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275359#comment-17275359
 ] 

Isabelle Giguere commented on SOLR-7642:


[~janhoy], [~gus] : I don't see the "Enable Patch Review" button
I think I did see that button previously, but now, I can't.  The documentation 
doesn't mention that the button would only be visible to Solr committers : 
https://cwiki.apache.org/confluence/display/SOLR/HowToContribute#HowToContribute-Contributingyourwork
Can one of you enable the patch review, if you feel it's appropriate ? 
Thanks.

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642.patch, SOLR-7642_tag_7.5.0.patch, 
> SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8319:
---
Attachment: (was: SOLR-7642.patch)

> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
>  Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
>   Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I 
> believe the problem is that when my analysis process is applied twice it 
> results in a null query. OK this might be seen as my issue because of dodgy 
> analysis, I thought it might be because I have the wrong order with 
> LengthFilterFactory before EnglishPossessiveFilterFactory and 
> KStemFilterFactory, i.e.:
> 
> 
>  
> So that "cat's" -> "cat" -> "", however any filter order I tried still 
> resulted in a NPE, and perhaps there is a viable case where parsing a term 
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has 
> to undergo any analysis. If the term is from the index can it not simply be 
> created using a TermQuery, which I would imagine would also be faster. I 
> altered the "getFieldQuery" line above to the following and that has fixed my 
> NPE issue.
>   Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use 
> of Solr, rather than actually fixing an issue. 
> o.a.s.c.SolrCore java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> 

[jira] [Updated] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8319:
---
Attachment: SOLR-7642.patch

> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
>  Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
>   Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I 
> believe the problem is that when my analysis process is applied twice it 
> results in a null query. OK this might be seen as my issue because of dodgy 
> analysis, I thought it might be because I have the wrong order with 
> LengthFilterFactory before EnglishPossessiveFilterFactory and 
> KStemFilterFactory, i.e.:
> 
> 
>  
> So that "cat's" -> "cat" -> "", however any filter order I tried still 
> resulted in a NPE, and perhaps there is a viable case where parsing a term 
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has 
> to undergo any analysis. If the term is from the index can it not simply be 
> created using a TermQuery, which I would imagine would also be faster. I 
> altered the "getFieldQuery" line above to the following and that has fixed my 
> NPE issue.
>   Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use 
> of Solr, rather than actually fixing an issue. 
> o.a.s.c.SolrCore java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> 

[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275287#comment-17275287
 ] 

Isabelle Giguere commented on SOLR-7642:


New patch, adressing Jan's comments.

The patch needs refguide docs. 
- done

Should it also be documented in bin/solr -h? 
- done

Should "/solr" be an always-whitelisted path? 
- Not useful if -DcreateZkRoot=true, because any path will be ceated

Nipick: Consider terminology - is it zkRoot or zkChRoot? 
- Keeping 'createZkRoot' in the new patch.  It at least avoids changing scripts 
on our side ;)
- I'm not a fan of "chroot".  Doesn't 'ch' mean "change" ?  So "createZKChRoot" 
would mean "create the zookeeper change root" ?
- It could be createZkNode ?  createZkPath ?


I can't find the test class TestZkChroot.java in master branch, so, no unit 
test this time.

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642.patch, SOLR-7642_tag_7.5.0.patch, 
> SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275287#comment-17275287
 ] 

Isabelle Giguere edited comment on SOLR-7642 at 1/29/21, 7:45 PM:
--

New patch, addressing [~janhoy] comments.

The patch needs refguide docs. 
- done

Should it also be documented in bin/solr -h? 
- done

Should "/solr" be an always-whitelisted path? 
- Not useful if -DcreateZkRoot=true, because any path will be ceated

Nipick: Consider terminology - is it zkRoot or zkChRoot? 
- Keeping 'createZkRoot' in the new patch.  It at least avoids changing scripts 
on our side ;)
- I'm not a fan of "chroot".  Doesn't 'ch' mean "change" ?  So "createZKChRoot" 
would mean "create the zookeeper change root" ?
- It could be createZkNode ?  createZkPath ?


I can't find the test class TestZkChroot.java in master branch, so, no unit 
test this time.


was (Author: igiguere):
New patch, adressing Jan's comments.

The patch needs refguide docs. 
- done

Should it also be documented in bin/solr -h? 
- done

Should "/solr" be an always-whitelisted path? 
- Not useful if -DcreateZkRoot=true, because any path will be ceated

Nipick: Consider terminology - is it zkRoot or zkChRoot? 
- Keeping 'createZkRoot' in the new patch.  It at least avoids changing scripts 
on our side ;)
- I'm not a fan of "chroot".  Doesn't 'ch' mean "change" ?  So "createZKChRoot" 
would mean "create the zookeeper change root" ?
- It could be createZkNode ?  createZkPath ?


I can't find the test class TestZkChroot.java in master branch, so, no unit 
test this time.

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642.patch, SOLR-7642_tag_7.5.0.patch, 
> SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7642:
---
Attachment: SOLR-7642.patch

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642.patch, SOLR-7642_tag_7.5.0.patch, 
> SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13209) NullPointerException from call in org.apache.solr.search.SolrIndexSearcher.getDocSet

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-13209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274593#comment-17274593
 ] 

Isabelle Giguere commented on SOLR-13209:
-

Throwing an exception for a null query makes sense for the request in the 
description.  This request is invalid, missing a value for group.query.

But the exception should not be thrown from such a low-level method, because it 
could impact faceting too, where the user doesn't have control over the queries 
that are produced by the faceting process.  Refer to SOLR-8319.

Group queries parameters should be validated, and an exception thrown right 
away.

> NullPointerException from call in 
> org.apache.solr.search.SolrIndexSearcher.getDocSet
> 
>
> Key: SOLR-13209
> URL: https://issues.apache.org/jira/browse/SOLR-13209
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will 
> allow you to reproduce the issue reported.
>Reporter: Cesar Rodriguez
>Priority: Minor
>  Labels: diffblue, newdev
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?group=true
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
>   at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:124)
>   at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:163)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:792)
>   at 
> org.apache.solr.search.Grouping$CommandQuery.createFirstPassCollector(Grouping.java:860)
>   at org.apache.solr.search.Grouping.execute(Grouping.java:327)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessGroupedSearch(QueryComponent.java:1408)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:365)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> [...]
> {noformat}
> Method {{org.apache.solr.search.SolrIndexSearcher.getDocSet()}}, at line 792 
> calls {{filterCache.get(absQ)}} where {{absQ}} is a null pointer. I think 
> this null pointer comes in fact from the caller, but I don't fully follow the 
> logic of the code.
> To set up an environment to reproduce this bug, follow the description in the 
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue 
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. 
> Find more information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274551#comment-17274551
 ] 

Isabelle Giguere edited comment on SOLR-8319 at 1/29/21, 5:00 PM:
--

The PR (937) in the linked issue SOLR-13209 suggest throwing a SolrException 
from SolrIndexSearcher.getDocSet(Query), which is certainly more elegant than 
an NPE.

I applied PR 937, on Solr 8.7.0, to see if I would get a SolrException for the 
facet request. I which case, I would have caught the exception, somewhere in 
the fact pivot processing (we shouldn't send an error message as a response for 
a valid facet pivot query).

But my facet pivot request still ends with NPE. The request goes through 
SolrIndexSearcher.numDocs(Query, DocSet) and 
SolrIndexSearcher.getPositiveDocSet(Query) :
{noformat}
Error from server at null: java.lang.NullPointerException at 
java.base/java.util.concurrent.ConcurrentHashMap.get(Unknown Source) at 
org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:163) at 
org.apache.solr.search.LFUCache.get(LFUCache.java:198) at 
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:846)
 at 
org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2069) 
at 
org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:355)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:218)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:166)
 at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:280)
 at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:360)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
{noformat}
The fact is, in a facet pivot request, the user has no actual control on the 
Query that ends up in methods of SolrIndexSearcher. The queries are generated 
from the facet field content. Checking for null, as in the attached patch, may 
be the only thing we can do.

It is strange, however, that setting a value for facet.limit will return 
results... or an NPE, depending on the value. 
>From my experiments, a facet.limit value of -1 returns all results, other 
>values return partial results, but only up to a point, after that, it's NPE.
facet.limit value: 
-1 = all results
0 = no results
Other value = partial results OR NPE
1 = 1 result
2 = 2 results
3 = 3 results
4 = NPE

So... Whatever happens when facet.limit=-1 is handled properly, but for values 
greater than (what ?) are not.
Default value for facet.limit is 100.  So, it's not even handling it's own 
default correctly.



was (Author: igiguere):
The PR (937) in the linked issue SOLR-13209 suggest throwing a SolrException 
from SolrIndexSearcher.getDocSet(Query), which is certainly more elegant than 
an NPE.

I applied PR 937, on Solr 8.7.0, to see if I would get a SolrException for the 
facet request. I which case, I would have caught the exception, somewhere in 
the fact pivot processing (we shouldn't send an error message as a response for 
a valid facet pivot query).

But my facet pivot request still ends with NPE. The request goes through 
SolrIndexSearcher.numDocs(Query, DocSet) and 
SolrIndexSearcher.getPositiveDocSet(Query) :
{noformat}
Error from server at null: java.lang.NullPointerException at 
java.base/java.util.concurrent.ConcurrentHashMap.get(Unknown Source) at 
org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:163) at 
org.apache.solr.search.LFUCache.get(LFUCache.java:198) at 
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:846)
 at 
org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2069) 
at 
org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:355)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:218)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:166)
 at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:280)
 at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:360)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795) at 

[jira] [Commented] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273951#comment-17273951
 ] 

Isabelle Giguere commented on SOLR-14886:
-

Note that the patch cannot fix the cases where the error message contains the 
full stack trace.

For example : SOLR-8319 (SOLR-8921)
Refer to this comment in SOLR-8921 for hints on how to generate an NPE, and you 
will see the stack trace in the error message.
https://issues.apache.org/jira/browse/SOLR-8921?focusedCommentId=16646667=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16646667

{code}


org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException

Error from server at null: java.lang.NullPointerException at 
java.base/java.util.concurrent.ConcurrentHashMap.get(Unknown Source) at 
org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:163) at 
org.apache.solr.search.LFUCache.get(LFUCache.java:198) at 
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:843)
 at 
org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2066) 
at 
org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:355)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:218)
 at 
org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:166)
 at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:280)
 at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:360)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590) 
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) 
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
 at 
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
 at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
 at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) 
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
 at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) 
at org.eclipse.jetty.server.Server.handle(Server.java:500) at 
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) at 
org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547) at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) at 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:335) at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
 at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
 at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
 at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135)
 at org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:170) 
at org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:125) 
at 

[jira] [Updated] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14886:

Attachment: SOLR-14886.patch

> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
> Attachments: SOLR-14886.patch
>
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273160#comment-17273160
 ] 

Isabelle Giguere commented on SOLR-14886:
-

Well... silly me.
After looking at QueryResponseWriter, method SolrCore.postDecorateResponse, and 
places where the "trace" element of the response is set, it occurred to me that 
all we need to do is block the stack trace from the HTTP response.

That's handled in ResponseUtils.

Patch off branch_8x, for a start.  It should eventually be adapted to master 
branch (Solr 9).
- Add a property "hideStackTrace" to solr.xml
- In NodeConfig, the default value is "false", for back-compatibility.
- Use the new property in ResponseUtils, to print out, or not, the stack trace.
- Adapt code that calls ResponseUtils

There's no direct path between solr.xml and ResponseUtils, or any class that 
uses ResponseUtils, so the "hideStackTrace" property is duplicated in 
CoreContainer, just so it lives in a place where it can be read.  May not be 
the best approach.




> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
> Attachments: SOLR-14886.patch
>
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270442#comment-17270442
 ] 

Isabelle Giguere edited comment on SOLR-14886 at 1/26/21, 9:04 PM:
---

We could easily add a parameter in solr.xml to hide (or not) stack traces:

But doing something with that parameter will not be easy.

I thought of a solution that would use that new parameter to modify the 
response just before sending it out, so the actual log file would not be 
affected.  Either adapt implementations of QueryResponseWriter, or method 
SolrCore.postDecorateResponse.

However, the "trace" element of the response seems to be set all over the code, 
instead of handling the Exception properly, or throwing it so it could be 
handled in a more generic way elsewhere.  These locations in code (at least 12 
that I can see in branch_8x, not counting unit tests) don't all have access to 
the config from solr.xml

For example, trying to sort results using a multi-valued field (a date field) 
yields this error.  The "error" and "trace" elements are set in 
QueryComponent.mergeIds.
{code}


class java.lang.String cannot be cast to class org.apache.lucene.util.BytesRef 
(java.lang.String is in module java.base of loader 'bootstrap'; 
org.apache.lucene.util.BytesRef is in unnamed module of loader 
org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0)


java.lang.ClassCastException: class java.lang.String cannot be cast to class 
org.apache.lucene.util.BytesRef (java.lang.String is in module java.base of 
loader 'bootstrap'; org.apache.lucene.util.BytesRef is in unnamed module of 
loader org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0) at 
org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:92)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
 at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:254) at 
org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:131) at 
org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:147) 
at 
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:958)
 at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:614)
 at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:593)
 at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:454)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:802) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:579) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
 at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) at 
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) 
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) 
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
 at 
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
 at 

[jira] [Commented] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270442#comment-17270442
 ] 

Isabelle Giguere commented on SOLR-14886:
-

We could easily add a parameter in solr.xml to hide (or not) stack traces:

But doing something with that parameter will not be easy.

I thought of a solution that would use that new parameter to modify the 
response just before sending it out, so the actual log file would not be 
affected.  Either adapt implementations of QueryResponseWriter, or method 
SolrCore.postDecorateResponse.

However, the "trace" element of the response seems to be set all over the code, 
instead of handling the Exception properly, or throwing it so it could be 
handled in a more generic way elsewhere.  These locations in code (at least 12 
that I can see in branch_8x, not counting unit tests) don't all have access to 
the config from solr.xml

For example, trying to sort results using a multi-valued field (a date field) 
yields this error.  The "error" and "trace" elements are set in 
QueryComponent.mergeIds.
{code}


class java.lang.String cannot be cast to class org.apache.lucene.util.BytesRef 
(java.lang.String is in module java.base of loader 'bootstrap'; 
org.apache.lucene.util.BytesRef is in unnamed module of loader 
org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0)


java.lang.ClassCastException: class java.lang.String cannot be cast to class 
org.apache.lucene.util.BytesRef (java.lang.String is in module java.base of 
loader 'bootstrap'; org.apache.lucene.util.BytesRef is in unnamed module of 
loader org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0) at 
org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:92)
 at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
 at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:254) at 
org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:131) at 
org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:147) 
at 
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:958)
 at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:614)
 at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:593)
 at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:454)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:802) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:579) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
 at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) at 
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602) 
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) 
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
 at 
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
 at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
 at 

[jira] [Comment Edited] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267462#comment-17267462
 ] 

Isabelle Giguere edited comment on SOLR-7913 at 1/18/21, 7:43 PM:
--

New patch on tag release/lucene-solr/8.5.0
I had forgotten to attach it when upgrading, last time.

IMPORTANT : There was a bug in previous patches.  Changes in SearchHandler and 
ShardRequest in the previous patches resulted in including the shard request 
URL in the "stream.body" passed to the MLT request.  That's why test results in 
CloudMLTQParserTest were different, when comparing the test with the id request 
(testMLTQParser) and the test with stream.body (testMLTQParserStreamBody).

Apply "SOLR-7913_fix-unit-test-setup.patch" on top of "SOLR-7913.patch" of 
today.


was (Author: igiguere):
New patch on tag release/lucene-solr/8.5.0
I had forgotten to attach it when upgrading, last time.

IMPORTANT : There was a bug in previous patches.  Changes in SearchHandler and 
ShardRequest in the previous patches resulted in including the shard request 
URL in the "stream.body" passed to the MLT request.  That's why test results in 
CloudMLTQParserTest were different, when comparing the test with the id request 
(testMLTQParser) and the test with stream.body (testMLTQParserStreamBody).

Apply SOLR-7913_fix-unit-test-setup.patch on top of SOLR-7913.patch

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267477#comment-17267477
 ] 

Isabelle Giguere edited comment on SOLR-7913 at 1/18/21, 7:43 PM:
--

MLT Query Parser was originally implemented to allow field queries (i.e.: 
myField:some text)
https://issues.apache.org/jira/browse/SOLR-6248
Read specifically the discussion between Steve Molloy, Vitaliy Zhovtyuk and 
Anshum Gupta in the first few comments.
By the time the MLT QParser was committed to SVN trunk, the query format was 
changed: 
https://issues.apache.org/jira/browse/SOLR-6248?focusedCommentId=14189235=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14189235
With this format, the input immediately following the closing curly brace is 
assumed to be a docId (whatever field is the unique id key in the schema)

As of now, without any of the patches on this ticket, the first thing that 
happens is to look for document by id, and if that fails, throw an exception.

This whole "stream.body" discussion (or monologue) originally started because 
of a need to identify a document using a query on any field, not just an id.

Maybe it's time to move away from the idea of "stream.body", and re-implement 
support for any field query in MLT QParser.

If the extra tests added in "SOLR-7913_negative-tests.patch" could produce 
results instead of an exception, I don't think anyone would need to use 
stream.body with an MLT QParser query.


was (Author: igiguere):
MLT Query Parser was originally implemented to allow field queries (i.e.: 
myField:some text)
https://issues.apache.org/jira/browse/SOLR-6248
Read specifically the discussion between Steve Molloy, Vitaliy Zhovtyuk and 
Anshum Gupta in the first few comments.
By the time the MLT QParser was committed to SVN trunk, the query format was 
changed: 
https://issues.apache.org/jira/browse/SOLR-6248?focusedCommentId=14189235=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14189235
With this format, the input immediately following the closing curly brace is 
assumed to be a docId (whatever field is the unique id key in the schema)

As of now, without any of the patches on this ticket, the first thing that 
happens is to look for document by id, and if that fails, throw an exception.

This whole "stream.body" discussion (or monologue) originally started because 
of a need to identify a document using a query on any field, not just an id.

Maybe it's time to move away from the idea of "stream.body", and re-implement 
support for any field query in MLT QParser.

If the extra tests added in SOLR-7913_negative-tests.patch could produce 
results instead of an exception, I don't think anyone would need to use 
stream.body with an MLT QParser query.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267477#comment-17267477
 ] 

Isabelle Giguere edited comment on SOLR-7913 at 1/18/21, 7:42 PM:
--

MLT Query Parser was originally implemented to allow field queries (i.e.: 
myField:some text)
https://issues.apache.org/jira/browse/SOLR-6248
Read specifically the discussion between Steve Molloy, Vitaliy Zhovtyuk and 
Anshum Gupta in the first few comments.
By the time the MLT QParser was committed to SVN trunk, the query format was 
changed: 
https://issues.apache.org/jira/browse/SOLR-6248?focusedCommentId=14189235=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14189235
With this format, the input immediately following the closing curly brace is 
assumed to be a docId (whatever field is the unique id key in the schema)

As of now, without any of the patches on this ticket, the first thing that 
happens is to look for document by id, and if that fails, throw an exception.

This whole "stream.body" discussion (or monologue) originally started because 
of a need to identify a document using a query on any field, not just an id.

Maybe it's time to move away from the idea of "stream.body", and re-implement 
support for any field query in MLT QParser.

If the extra tests added in SOLR-7913_negative-tests.patch could produce 
results instead of an exception, I don't think anyone would need to use 
stream.body with an MLT QParser query.


was (Author: igiguere):
MLT Query Parser was originally implemented to allow field queries (i.e.: 
myField:some text)
https://issues.apache.org/jira/browse/SOLR-6248
Read specifically the discussion between Steve Molloy, Vitaliy Zhovtyuk and 
Anshum Gupta in the first few comments.
By the time the MLT QParser was committed to SVN trunk, the query format was 
changed: 
https://issues.apache.org/jira/browse/SOLR-6248?focusedCommentId=14189235=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14189235
With this format, the input immediately following the closing curly brace is 
assumed to be a docId (whatever field is the unique id key in the schema)

In CloudMLTQParser, without any of the patches on this ticket, the first thing 
that happens is to look for document by id, and if that fails, throw an 
exception.

This whole "stream.body" discussion (or monologue) originally started because 
of a need to identify a document using a query on any field, not just an id.

Maybe it's time to move away from the idea of "stream.body", and re-implement 
support for any field query in MLT QParser.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913_negative-tests.patch

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_negative-tests.patch, 
> SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267477#comment-17267477
 ] 

Isabelle Giguere commented on SOLR-7913:


MLT Query Parser was originally implemented to allow field queries (i.e.: 
myField:some text)
https://issues.apache.org/jira/browse/SOLR-6248
Read specifically the discussion between Steve Molloy, Vitaliy Zhovtyuk and 
Anshum Gupta in the first few comments.
By the time the MLT QParser was committed to SVN trunk, the query format was 
changed: 
https://issues.apache.org/jira/browse/SOLR-6248?focusedCommentId=14189235=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14189235
With this format, the input immediately following the closing curly brace is 
assumed to be a docId (whatever field is the unique id key in the schema)

In CloudMLTQParser, without any of the patches on this ticket, the first thing 
that happens is to look for document by id, and if that fails, throw an 
exception.

This whole "stream.body" discussion (or monologue) originally started because 
of a need to identify a document using a query on any field, not just an id.

Maybe it's time to move away from the idea of "stream.body", and re-implement 
support for any field query in MLT QParser.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267462#comment-17267462
 ] 

Isabelle Giguere edited comment on SOLR-7913 at 1/18/21, 7:10 PM:
--

New patch on tag release/lucene-solr/8.5.0
I had forgotten to attach it when upgrading, last time.

IMPORTANT : There was a bug in previous patches.  Changes in SearchHandler and 
ShardRequest in the previous patches resulted in including the shard request 
URL in the "stream.body" passed to the MLT request.  That's why test results in 
CloudMLTQParserTest were different, when comparing the test with the id request 
(testMLTQParser) and the test with stream.body (testMLTQParserStreamBody).

Apply SOLR-7913_fix-unit-test-setup.patch on top of SOLR-7913.patch


was (Author: igiguere):
New patch on tag release/lucene-solr/8.5.0
I had forgotten to attach it when upgrading, last time.

IMPORTANT : There was a bug in previous patches.  Changes in SearchHandler and 
ShardRequest in the previous patches resulted in including the shard request 
URL in the "stream.body" passed to the MLT request.  That's why test results in 
CloudMLTQParserTest were different, when comparing the test with the id request 
(testMLTQParser) and the test with stream.body (testMLTQParserStreamBody).

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913_fix-unit-test-setup.patch

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fix-unit-test-setup.patch, 
> SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267462#comment-17267462
 ] 

Isabelle Giguere commented on SOLR-7913:


New patch on tag release/lucene-solr/8.5.0
I had forgotten to attach it when upgrading, last time.

IMPORTANT : There was a bug in previous patches.  Changes in SearchHandler and 
ShardRequest in the previous patches resulted in including the shard request 
URL in the "stream.body" passed to the MLT request.  That's why test results in 
CloudMLTQParserTest were different, when comparing the test with the id request 
(testMLTQParser) and the test with stream.body (testMLTQParserStreamBody).

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913.patch

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913_fixTests.patch, SOLR-7913_tag_7.5.0.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249854#comment-17249854
 ] 

Isabelle Giguere edited comment on SOLR-14886 at 12/15/20, 6:45 PM:


[~gerlowskija]
The full stack trace in the error response can be a vulnerability.

As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information 
about the application and database that could be used to conduct an attack. 
This information could include the names of database tables and columns, the 
structure of database queries, method names, configuration details, etc.
{quote}

So, OK, no database here.  But the basic idea is that the stack trace contains 
too much information for a response to the outside world.  Stack traces are for 
logs, for developers.

It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each and every error message needs to be cleaned-up individually, 
which is error-prone, or, we don't display any details to the outside world.

Because the stack trace lists all classes and methods, a hacker can determine 
which vulnerable library is included on the classpath.  So in this sense, even 
information about the classpath is sensitive information.



was (Author: igiguere):
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.

As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information 
about the application and database that could be used to conduct an attack. 
This information could include the names of database tables and columns, the 
structure of database queries, method names, configuration details, etc.
{quote}

So, OK, no database here.  But the basic idea is that the stack trace contains 
too much information for a response to the outside world.  Stack traces are for 
logs, for developers.

It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each an every error message needs to be cleaned-up individually, 
which is error-prone, or, we don't display any details to the outside world.

Because the stack trace lists all classes and methods, a hacker can determine 
which vulnerable library is included on the classpath.  So in this sense, even 
information about the classpath is sensitive information.


> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249854#comment-17249854
 ] 

Isabelle Giguere edited comment on SOLR-14886 at 12/15/20, 6:44 PM:


[~gerlowskija]
The full stack trace in the error response can be a vulnerability.

As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information 
about the application and database that could be used to conduct an attack. 
This information could include the names of database tables and columns, the 
structure of database queries, method names, configuration details, etc.
{quote}

So, OK, no database here.  But the basic idea is that the stack trace contains 
too much information for a response to the outside world.  Stack traces are for 
logs, for developers.

It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each an every error message needs to be cleaned-up individually, 
which is error-prone, or, we don't display any details to the outside world.

Because the stack trace lists all classes and methods, a hacker can determine 
which vulnerable library is included on the classpath.  So in this sense, even 
information about the classpath is sensitive information.



was (Author: igiguere):
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.

As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information 
about the application and database that could be used to conduct an attack. 
This information could include the names of database tables and columns, the 
structure of database queries, method names, configuration details, etc.
{quote}

So, OK, no database here.  But the basic idea is that the stack trace contains 
too much information for a response.


> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14886) Suppress stack trace in Query response.

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249854#comment-17249854
 ] 

Isabelle Giguere commented on SOLR-14886:
-

[~gerlowskija]
The full stack trace in the error response can be a vulnerability.

As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information 
about the application and database that could be used to conduct an attack. 
This information could include the names of database tables and columns, the 
structure of database queries, method names, configuration details, etc.
{quote}

So, OK, no database here.  But the basic idea is that the stack trace contains 
too much information for a response.


> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
>
> Currently there is no way to suppress the stack trace in solr response when 
> it throws an exception, like when a client sends a badly formed query string, 
> or exception with status 500 It sends full stack trace in the response. 
> I would propose a configuration for error messages so that the stack trace is 
> not visible to avoid any sensitive information in the stack trace.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Status: Patch Available  (was: Open)

> Configuring a shardHandlerFactory on the /select requestHandler results in 
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> Update: Fast-forward to this comment for the reason why: 
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler 
> in configset cloud-minimal
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with attached configuration solr_conf.zip or updated_solr_conf.zip:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150553#comment-17150553
 ] 

Isabelle Giguere commented on SOLR-14569:
-

Attached a patch with a fix.
This patch fixes the SearchHandler only, I have not looked at other request 
handlers, and it may not be the most elegant fix.

Analysis: 
When a shard handler factory is configured directly on a request handler (a 
search handler), in solconfig.xml, method SearchHandler.inform(SolrCore) 
creates a new instance of ShardHandlerFactory.  But in this case, the security 
builder of the shard handler factory remains null.

Fix:
Add a boolean marker in ShardHandlerFactory, to indicate if security was 
initialized, and method to get the marker.
In SearchHandler.inform(SolrCore), after the new instance of 
ShardHandlerFactory is created, verify if security was enabled.  In this patch, 
call the CoreContainer method getAuthenticationPlugin() and check that it's not 
null.  We may want to use another marker somewhere, if it can be cleaner.
Also verify if security was enabled in the new shard handler factory, using the 
new marker in ShardHandlerFactory.
If security is enabled but the new shard handler factory is not initialized for 
it, then set the security builder, by providing the core container's PKI 
authentication plugin, following what is done in 
CoreContainer.setupHttpClientForAuthPlugin(...)

Adding unit test class TestAuthWithShardHandlerFactoryOverride, and configset.

Note that if you comment-out the lines that set the security builder in 
SearchHandler.inform(SolrCore), and try to run these unit tests, they fail with:
{noformat}
org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: 
Authentication challenge without WWW-Authenticate header
{noformat}
So it's not exactly the same error as seen from a query run in Solr Admin UI or 
a REST client.  But it at least shows there's something wrong with 
authentication.  I suppose the HTTP protocol violation error is translated into 
HTTP 401 in a part of code that the unit test doesn't reach.


Is there some other way to ensure that the search handler's specific shard 
handler factory is made aware of security settings ?


> Configuring a shardHandlerFactory on the /select requestHandler results in 
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> Update: Fast-forward to this comment for the reason why: 
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler 
> in configset cloud-minimal
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with attached configuration solr_conf.zip or updated_solr_conf.zip:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n 

[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: SOLR-14569.patch

> Configuring a shardHandlerFactory on the /select requestHandler results in 
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> Update: Fast-forward to this comment for the reason why: 
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler 
> in configset cloud-minimal
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with attached configuration solr_conf.zip or updated_solr_conf.zip:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*
Update: Fast-forward to this comment for the reason why: 
https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195

The attached patch includes a unit test to query on an alias.  *Fixed and 
updated as per [~gerlowskija]' comments*
 *Patch applies on master branch (9x)*.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.
Update: Unit tests fail if sharHandlerFactory is added to the requestHandler in 
configset cloud-minimal

I also attach:
 - our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
 - security.json with user 'admin' (pwd 'admin')
 -- Note that forwardCredentials true or false does not modify the behavior

To test with attached configuration solr_conf.zip or updated_solr_conf.zip:
 - Download and unzip Solr 8.5.0
 - Modify ./bin/solr.in.sh :
 -- ZK_HOST (optional)
 -- SOLR_AUTH_TYPE="basic"
 -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
 - Upload security.json into Zookeeper
 -- ./bin/solr zk cp 
[file:/path/to/security.json|file:///path/to/security.json] 
zk:/path/to/solr/security.json [-z :[/]]
 - Start Solr in cloud mode
 -- ./bin/solr -c
 - Upload the provided configuration
 - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
 - Create 2 collections using the uploaded configuration
 -- test1, test2
 - Create an alias grouping the 2 collections
 -- test = test1, test2
 - Query (/select?q=*:*) one collection
 -- results in successful Solr response
 - Query the alias (/select?q=*:*)
 -- results in HTTP 401

There is no need to add documents to observe the issue.

  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test to query on an alias.  *Fixed and 
updated as per [~gerlowskija]' comments*
 *Patch applies on master branch (9x)*.
 The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
 - our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
 - security.json with user 'admin' (pwd 'admin')
 -- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
 - Download and unzip Solr 8.5.0
 - Modify ./bin/solr.in.sh :
 -- ZK_HOST (optional)
 -- SOLR_AUTH_TYPE="basic"
 -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
 - Upload security.json into Zookeeper
 -- ./bin/solr zk cp 
[file:/path/to/security.json|file:///path/to/security.json] 
zk:/path/to/solr/security.json [-z :[/]]
 - Start Solr in cloud mode
 -- ./bin/solr -c
 - Upload the provided configuration
 - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
 - Create 2 collections using the uploaded configuration
 -- test1, test2
 - Create an alias grouping the 2 collections
 -- test = test1, test2
 - Query (/select?q=*:*) one collection
 -- results in successful Solr response
 - Query the alias (/select?q=*:*)
 -- results in HTTP 401

There is no need to add documents to observe the issue.


> Configuring a shardHandlerFactory on the /select requestHandler results in 
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> 

[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Summary: Configuring a shardHandlerFactory on the /select requestHandler 
results in HTTP 401 when searching on alias in secured Solr  (was: HTTP 401 
when searching on alias in secured Solr)

> Configuring a shardHandlerFactory on the /select requestHandler results in 
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136195#comment-17136195
 ] 

Isabelle Giguere edited comment on SOLR-14569 at 6/15/20, 11:21 PM:


It took a lot of trial and error, but... I figured it out.

There's a shardHandlerFactory defined in some of the requestHandler in 
solrconfig.xml.  There's also the global shardHandlerFactory defined in solr.xml

Defining a specific shardHandlerFactory in the /select requestHandler somehow 
prevents the SolrAuth from being transferred to shard requests.

Ref: solrconfig.xml in the attached configuration(s)
{code}

   
5
5
5

{code}

If the shardHandlerFactory in the /select requestHandler is removed, the query 
on an alias magically works.  Authentication info is sent to shards.

What kills me is why...
I went through CHANGES.txt to find hints about why overriding the global 
shardHandlerFactory would cause any sort of failures.  The only thing I could 
find was the mention that since Solr 8.0.0, "HttpShardHandlerFactory's 
defaultClient is now a Http2SolrClient".  The parameters 'maxConnections', 
'maxConnectionsPerHost', which are not supported anymore, and thus could have 
been a good reason for a failure, are found neither in solr.xml, nor in 
solrconfig.xml.

A quick look at ShardHandlerFactory, HttpShardHandlerFactory, HttpShardHandler, 
RequestHandlerBase, SearchHandler does not provide any obvious explanation 
either.

Actually, documentation clearly states that a shardHandlerFactory can be set 
for a requestHandler: 
https://lucene.apache.org/solr/guide/8_5/distributed-requests.html

So I'm changing the title of this ticket.  There is something odd here.  But at 
least there's a workaround : do not configure a specific shardHandlerFactory on 
a requestHandler (especially not the /select search handler)



was (Author: igiguere):
It took a lot of trial and error, but... I figured it out.

There's a shardHandlerFactory defined in some of the requestHandler in 
solrconfig.xml.  There's also the global shardHandlerFactory defined in solr.xml

Defining a specific shardHandlerFactory in the /select requestHandler somehow 
prevents the SolrAuth from being transferred to shard requests.

Ref: solrconfig.xml in the attached configuration(s)
{code}

   
5
5
5

{code}

If the shardHandlerFactory in the /select requestHandler is removed, the query 
on an alias magically works.  Authentication info is sent to shards.

What kills me is why...
I went through CHANGES.txt to find hints about why overriding the global 
shardHandlerFactory would cause any sort of failures.  The only thing I could 
find was the mention that since Solr 8.0.0, "HttpShardHandlerFactory's 
defaultClient is now a Http2SolrClient".  The parameters 'maxConnections', 
'maxConnectionsPerHost', which are not supported anymore, and thus could have 
been a good reason for a failure, are found neither in solr.xml, nor in 
solrconfig.xml.

A quick look at ShardHandlerFactory, HttpShardHandlerFactory, HttpShardHandler, 
RequestHandlerBase, SearchHandler does not provide any obvious explanation 
either.

Sigh...



> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To 

[jira] [Commented] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136195#comment-17136195
 ] 

Isabelle Giguere commented on SOLR-14569:
-

It took a lot of trial and error, but... I figured it out.

There's a shardHandlerFactory defined in some of the requestHandler in 
solrconfig.xml.  There's also the global shardHandlerFactory defined in solr.xml

Defining a specific shardHandlerFactory in the /select requestHandler somehow 
prevents the SolrAuth from being transferred to shard requests.

Ref: solrconfig.xml in the attached configuration(s)
{code}

   
5
5
5

{code}

If the shardHandlerFactory in the /select requestHandler is removed, the query 
on an alias magically works.  Authentication info is sent to shards.

What kills me is why...
I went through CHANGES.txt to find hints about why overriding the global 
shardHandlerFactory would cause any sort of failures.  The only thing I could 
find was the mention that since Solr 8.0.0, "HttpShardHandlerFactory's 
defaultClient is now a Http2SolrClient".  The parameters 'maxConnections', 
'maxConnectionsPerHost', which are not supported anymore, and thus could have 
been a good reason for a failure, are found neither in solr.xml, nor in 
solrconfig.xml.

A quick look at ShardHandlerFactory, HttpShardHandlerFactory, HttpShardHandler, 
RequestHandlerBase, SearchHandler does not provide any obvious explanation 
either.

Sigh...



> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136158#comment-17136158
 ] 

Isabelle Giguere edited comment on SOLR-14569 at 6/15/20, 9:40 PM:
---

Attached:

- updated_solr_conf.zip : "Same" as solr_conf.zip, but with the deprecated 
Trie*Fields and Filters replaced by current equivalents.
- curl_requests-responses.txt : copy of activity on console for the 2 requests 
shown in solr.log
-  solr.log : shows 2 requests to Solr where  updated_solr_conf.zip was 
uploaded, and security and collections were setup as is the description

A few lines to help reading solr.log :
- line 1243:
-- Start GET request on one collection
- line 1323:
-- Response : 200
- line 1391:
-- Start GET request on alias
- line 1746:
-- POST request to core test1_shard1_replica_n1
- line 1803:
-- POST request to core test2_shard1_replica_n1
- line 2974:
-- Response : 401
- line 3311:
-- Solr response with HTTP 401

Extra note: upgrading Lucene Match version to 8.5.0 still fails for the alias.


was (Author: igiguere):
Attached:

- updated_solr_conf.zip : "Same" as solr_conf.zip, but with the deprecated 
Trie*Fields and Filters replaced by current equivalents.
- curl_requests-responses.txt : copy of activity on console for the 2 requests 
shown in solr.log
-  solr.log : shows 2 requests to Solr where  updated_solr_conf.zip was 
uploaded, and security and collections were setup as is the description

A few lines to help reading solr.log :
- line 1243:
-- Start GET request on one collection
- line 1323:
-- Response : 200
- line 1391:
-- Start GET request on alias
- line 1746:
-- POST request to core test1_shard1_replica_n1
- line 1803:
-- POST request to core test2_shard1_replica_n1
- line 2974:
-- Response : 401
- line 3311:
-- Solr response with HTTP 401

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: curl_requests-responses.txt

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136158#comment-17136158
 ] 

Isabelle Giguere commented on SOLR-14569:
-

Attached:

- updated_solr_conf.zip : "Same" as solr_conf.zip, but with the deprecated 
Trie*Fields and Filters replaced by current equivalents.
- curl_requests-responses.txt : copy of activity on console for the 2 requests 
shown in solr.log
-  solr.log : shows 2 requests to Solr where  updated_solr_conf.zip was 
uploaded, and security and collections were setup as is the description

A few lines to help reading solr.log :
- line 1243:
-- Start GET request on one collection
- line 1323:
-- Response : 200
- line 1391:
-- Start GET request on alias
- line 1746:
-- POST request to core test1_shard1_replica_n1
- line 1803:
-- POST request to core test2_shard1_replica_n1
- line 2974:
-- Response : 401
- line 3311:
-- Solr response with HTTP 401

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, 
> curl_requests-responses.txt, security.json, security.json, solr.log, 
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: updated_solr_conf.zip

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, security.json, 
> security.json, solr.log, solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: solr.log

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, security.json, 
> security.json, solr.log, solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test to query on an alias.  *Fixed and 
updated as per [~gerlowskija]' comments*
 *Patch applies on master branch (9x)*.
 The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
 - our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
 - security.json with user 'admin' (pwd 'admin')
 -- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
 - Download and unzip Solr 8.5.0
 - Modify ./bin/solr.in.sh :
 -- ZK_HOST (optional)
 -- SOLR_AUTH_TYPE="basic"
 -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
 - Upload security.json into Zookeeper
 -- ./bin/solr zk cp 
[file:/path/to/security.json|file:///path/to/security.json] 
zk:/path/to/solr/security.json [-z :[/]]
 - Start Solr in cloud mode
 -- ./bin/solr -c
 - Upload the provided configuration
 - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
 - Create 2 collections using the uploaded configuration
 -- test1, test2
 - Create an alias grouping the 2 collections
 -- test = test1, test2
 - Query (/select?q=*:*) one collection
 -- results in successful Solr response
 - Query the alias (/select?q=*:*)
 -- results in HTTP 401

There is no need to add documents to observe the issue.

  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*


The attached patch includes a unit test that reproduces the issue.
 *Patch applies on master branch (9x)*: Do not include in the regular build ! 
The test is failing to illustrate this issue.
 The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
 - our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
 - security.json with user 'admin' (pwd 'admin')
 -- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
 - Download and unzip Solr 8.5.0
 - Modify ./bin/solr.in.sh :
 -- ZK_HOST (optional)
 -- SOLR_AUTH_TYPE="basic"
 -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
 - Upload security.json into Zookeeper
 -- ./bin/solr zk cp 
[file:/path/to/security.json|file:///path/to/security.json] 
zk:/path/to/solr/security.json [-z :[/]]
 - Start Solr in cloud mode
 -- ./bin/solr -c
 - Upload the provided configuration
 - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
 - Create 2 collections using the uploaded configuration
 -- test1, test2
 - Create an alias grouping the 2 collections
 -- test = test1, test2
 - Query (/select?q=*:*) one collection
 -- results in successful Solr response
 - Query the alias (/select?q=*:*)
 -- results in HTTP 401

There is no need to add documents to observe the issue.


> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, security.json, 
> security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias.  *Fixed and 
> updated as per [~gerlowskija]' comments*
>  *Patch applies on master branch (9x)*.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr 

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: SOLR-14569.patch

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, security.json, 
> security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
>  *Patch applies on master branch (9x)*: Do not include in the regular build ! 
> The test is failing to illustrate this issue.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
>  - security.json with user 'admin' (pwd 'admin')
>  -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
>  - Download and unzip Solr 8.5.0
>  - Modify ./bin/solr.in.sh :
>  -- ZK_HOST (optional)
>  -- SOLR_AUTH_TYPE="basic"
>  -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
>  - Upload security.json into Zookeeper
>  -- ./bin/solr zk cp 
> [file:/path/to/security.json|file:///path/to/security.json] 
> zk:/path/to/solr/security.json [-z :[/]]
>  - Start Solr in cloud mode
>  -- ./bin/solr -c
>  - Upload the provided configuration
>  - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
>  - Create 2 collections using the uploaded configuration
>  -- test1, test2
>  - Create an alias grouping the 2 collections
>  -- test = test1, test2
>  - Query (/select?q=*:*) one collection
>  -- results in successful Solr response
>  - Query the alias (/select?q=*:*)
>  -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*


The attached patch includes a unit test that reproduces the issue.
 *Patch applies on master branch (9x)*: Do not include in the regular build ! 
The test is failing to illustrate this issue.
 The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
 - our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
 - security.json with user 'admin' (pwd 'admin')
 -- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
 - Download and unzip Solr 8.5.0
 - Modify ./bin/solr.in.sh :
 -- ZK_HOST (optional)
 -- SOLR_AUTH_TYPE="basic"
 -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
 - Upload security.json into Zookeeper
 -- ./bin/solr zk cp 
[file:/path/to/security.json|file:///path/to/security.json] 
zk:/path/to/solr/security.json [-z :[/]]
 - Start Solr in cloud mode
 -- ./bin/solr -c
 - Upload the provided configuration
 - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
 - Create 2 collections using the uploaded configuration
 -- test1, test2
 - Create an alias grouping the 2 collections
 -- test = test1, test2
 - Query (/select?q=*:*) one collection
 -- results in successful Solr response
 - Query the alias (/select?q=*:*)
 -- results in HTTP 401

There is no need to add documents to observe the issue.

  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=\*:\*) one collection
-- results in successful Solr response
- Query the alias (/select?q=\*:\*)
-- results in HTTP 401

There is no need to add documents to observe the issue.



> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
>  *Patch applies on master branch (9x)*: Do not include in the regular build ! 
> The test is failing to illustrate this issue.
>  The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
>  - our product-specific Solr 

[jira] [Comment Edited] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136056#comment-17136056
 ] 

Isabelle Giguere edited comment on SOLR-14569 at 6/15/20, 5:45 PM:
---

Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).  And I just 
tested again, to be sure, with valid security.json, and attached config.  
Result is still HTTP 401 for me (on CentOS 7.7, if that matters)

I just ran the unit test again, with the right password.  It passed ! It means 
there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.  There's no documented 
incompatibility that I'm aware of.


was (Author: igiguere):
Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).  And I just 
tested again, to be sure, with valid security.json, and attached config.  
Result is still HTTP 401 for me (on CentOS 7.7, if that matters)

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=\*:\*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=\*:\*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136056#comment-17136056
 ] 

Isabelle Giguere edited comment on SOLR-14569 at 6/15/20, 5:43 PM:
---

Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).  And I just 
tested again, to be sure, with valid security.json, and attached config.  
Result is still HTTP 401 for me (on CentOS 7.7, if that matters)

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.


was (Author: igiguere):
Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).  And I just 
tested again, to be sure, with valid security.json, at attached config.

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=\*:\*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=\*:\*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136056#comment-17136056
 ] 

Isabelle Giguere edited comment on SOLR-14569 at 6/15/20, 5:42 PM:
---

Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).  And I just 
tested again, to be sure, with valid security.json, at attached config.

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.


was (Author: igiguere):
Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=\*:\*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=\*:\*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136056#comment-17136056
 ] 

Isabelle Giguere commented on SOLR-14569:
-

Hi [~gerlowskija]

Good catches.  Sorry.  Trying to work fast... ;)

I did encounter the issue, at first, with a valid security.json.  The one I 
uploaded does have a typo in it.  Correcting it (new upload).

I'm running the unit test again, with the right password.  If it passes... It 
means there's something wrong with the configuration.

But how can solrconfig.xml or schema.xml have an impact on authentication, or 
alias queries in general ?  That doesn't make sense.

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=\*:\*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=\*:\*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: security.json

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, security.json, 
> solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=\*:\*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=\*:\*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=\*:\*) one collection
-- results in successful Solr response
- Query the alias (/select?q=\*:\*)
-- results in HTTP 401

There is no need to add documents to observe the issue.


  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401

There is no need to add documents to observe the issue.



> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - 

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401

There is no need to add documents to observe the issue.


  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401





> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that 

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

*Note that this issue is not reproduced when the collections are created using 
the _default configuration.*

The attached patch includes a unit test that reproduces the issue.
*Patch applies on master branch (9x)*: Do not include in the regular build !  
The test is failing to illustrate this issue.
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401




  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

Note that this issue is not reproduced when the collections are created using 
the _default configuration.

The attached patch includes a unit test that reproduces the issue.  Patch 
applies on master branch (9x).
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401





> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created 
> using the _default configuration.*
> The attached patch includes a unit test that reproduces the issue.
> *Patch applies on master branch (9x)*: Do not include in the regular build !  
> The test is failing to illustrate this issue.
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify 

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: solr_conf.zip

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json, solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> Note that this issue is not reproduced when the collections are created using 
> the _default configuration.
> The attached patch includes a unit test that reproduces the issue.  Patch 
> applies on master branch (9x).
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=*:*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=*:*)
> -- results in HTTP 401



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: security.json

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, security.json
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> Note that this issue is not reproduced when the collections are created using 
> the _default configuration.
> The attached patch includes a unit test that reproduces the issue.  Patch 
> applies on master branch (9x).
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=*:*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=*:*)
> -- results in HTTP 401



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Description: 
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

Note that this issue is not reproduced when the collections are created using 
the _default configuration.

The attached patch includes a unit test that reproduces the issue.  Patch 
applies on master branch (9x).
The unit test is added to the test class that was originally part of the patch 
to fix SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401




  was:
The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

Note that this issue is not reproduced when the collections are created using 
the _default configuration.

The attached patch includes a unit test that reproduces the issue.  The unit 
test is added to the test class that was originally part of the patch to fix 
SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401





> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> Note that this issue is not reproduced when the collections are created using 
> the _default configuration.
> The attached patch includes a unit test that reproduces the issue.  Patch 
> applies on master branch (9x).
> The unit test is added to the test class that was originally part of the 
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json 

[jira] [Updated] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-14569:

Attachment: SOLR-14569.patch

> HTTP 401 when searching on alias in secured Solr
> 
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with 
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
> with security.json.
> Searching on a single collection returns the expected results, but searching 
> on an alias returns HTTP 401.
> Note that this issue is not reproduced when the collections are created using 
> the _default configuration.
> The attached patch includes a unit test that reproduces the issue.  The unit 
> test is added to the test class that was originally part of the patch to fix 
> SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant 
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh : 
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp file:/path/to/security.json 
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z :[/] -n conf_en -d 
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=*:*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=*:*)
> -- results in HTTP 401



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14569) HTTP 401 when searching on alias in secured Solr

[Isabelle Giguere (Jira)]

Isabelle Giguere created SOLR-14569:
---

 Summary: HTTP 401 when searching on alias in secured Solr
 Key: SOLR-14569
 URL: https://issues.apache.org/jira/browse/SOLR-14569
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Authentication
Affects Versions: 8.5, master (9.0)
 Environment: Unit test on master branch (9x) built on Windows 10 with 
Java 11
Solr 8.5.0 instance running on CentOS 7.7 with Java 11
Reporter: Isabelle Giguere


The issue was first noticed on an instance of Solr 8.5.0, after securing Solr 
with security.json.

Searching on a single collection returns the expected results, but searching on 
an alias returns HTTP 401.

Note that this issue is not reproduced when the collections are created using 
the _default configuration.

The attached patch includes a unit test that reproduces the issue.  The unit 
test is added to the test class that was originally part of the patch to fix 
SOLR-13510.

I also attach:
- our product-specific Solr configuration, modified to remove irrelevant 
plugins and fields
- security.json with user 'admin' (pwd 'admin')
-- Note that forwardCredentials true or false does not modify the behavior

To test with this configuration:
- Download and unzip Solr 8.5.0
- Modify ./bin/solr.in.sh : 
-- ZK_HOST (optional)
-- SOLR_AUTH_TYPE="basic"
-- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
- Upload security.json into Zookeeper
-- ./bin/solr zk cp file:/path/to/security.json zk:/path/to/solr/security.json 
[-z :[/]]
- Start Solr in cloud mode
-- ./bin/solr -c
- Upload the provided configuration
- ./bin/solr zk upconfig -z :[/] -n conf_en -d 
/path/to/folder/conf/
- Create 2 collections using the uploaded configuration
-- test1, test2
- Create an alias grouping the 2 collections
-- test = test1, test2
- Query (/select?q=*:*) one collection
-- results in successful Solr response
- Query the alias (/select?q=*:*)
-- results in HTTP 401






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090040#comment-17090040
 ] 

Isabelle Giguere commented on SOLR-8394:


Hi [~dsmiley];
The real-world circumstance is easy : just use the luke handler, after adding a 
few documents in Solr.

http://localhost:8983/solr//admin/luke?wt=xml

Or, if you mean who exactly would need to read indexHeapUsageBytes and in what 
circumstances...  I think it may be useful to estimate a cluster size (as in 
SOLR-8393)

As for the code improvement... I'll try to get around to it.

> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8393) Component for Solr resource usage planning

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089176#comment-17089176
 ] 

Isabelle Giguere commented on SOLR-8393:


Attached patch, off current Git master.
Same patch as was proposed in 2017, Solr 6.6 at the time

> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run 
> Solr. The most common response is that it highly depends on your data. While 
> true, it makes for frustrated users trying to plan their deployments. 
> The idea I'm bringing is to create a new component that will attempt to 
> extrapolate resources needed in the future by looking at resources currently 
> used. By adding a parameter for the target number of documents, current 
> resources are adapted by a ratio relative to current number of documents.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8393) Component for Solr resource usage planning

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8393:
---
Attachment: SOLR-8393.patch

> Component for Solr resource usage planning
> --
>
> Key: SOLR-8393
> URL: https://issues.apache.org/jira/browse/SOLR-8393
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, SOLR-8393.patch, 
> SOLR-8393.patch, SOLR-8393_tag_7.5.0.patch
>
>
> One question that keeps coming back is how much disk and RAM do I need to run 
> Solr. The most common response is that it highly depends on your data. While 
> true, it makes for frustrated users trying to plan their deployments. 
> The idea I'm bringing is to create a new component that will attempt to 
> extrapolate resources needed in the future by looking at resources currently 
> used. By adding a parameter for the target number of documents, current 
> resources are adapted by a ratio relative to current number of documents.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088204#comment-17088204
 ] 

Isabelle Giguere commented on SOLR-7642:


Patch attached, off current master.  This patch is still the original 
proposition : just add -DcreateZkRoot=true on start-up.

Ex : "/opt/solr/bin/solr start -f -z zookeeper:2181/solr555 -DcreateZkRoot=true"

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-7642) Should launching Solr in cloud mode using a ZooKeeper chroot create the chroot znode if it doesn't exist?

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-7642:
---
Attachment: SOLR-7642.patch

> Should launching Solr in cloud mode using a ZooKeeper chroot create the 
> chroot znode if it doesn't exist?
> -
>
> Key: SOLR-7642
> URL: https://issues.apache.org/jira/browse/SOLR-7642
> Project: Solr
>  Issue Type: Improvement
>Reporter: Timothy Potter
>Priority: Minor
> Attachments: SOLR-7642.patch, SOLR-7642.patch, SOLR-7642.patch, 
> SOLR-7642_tag_7.5.0.patch, SOLR-7642_tag_7.5.0_proposition.patch
>
>
> If you launch Solr for the first time in cloud mode using a ZooKeeper 
> connection string that includes a chroot leads to the following 
> initialization error:
> {code}
> ERROR - 2015-06-05 17:15:50.410; [   ] org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.cloud.ZooKeeperException: A chroot was specified 
> in ZkHost but the znode doesn't exist. localhost:2181/lan
> at 
> org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:339)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:140)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:110)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:138)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:852)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
> {code}
> The work-around for this is to use the scripts/cloud-scripts/zkcli.sh script 
> to create the chroot znode (bootstrap action does this).
> I'm wondering if we shouldn't just create the znode if it doesn't exist? Or 
> is that some violation of using a chroot?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646656#comment-16646656
 ] 

Isabelle Giguere edited comment on SOLR-8394 at 4/20/20, 8:28 PM:
--

SOLR-8394_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest 
release
*** patch deleted ***

Simple test:
http://localhost:8983/solr/all/admin/luke?wt=xml
- without the patch : -1
-- -1 is the default return value !
- fixed by the patch : 299034



was (Author: igiguere):
SOLR-8394_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest 
release

Simple test:
http://localhost:8983/solr/all/admin/luke?wt=xml
- without the patch : -1
-- -1 is the default return value !
- fixed by the patch : 299034


> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646656#comment-16646656
 ] 

Isabelle Giguere edited comment on SOLR-8394 at 4/20/20, 8:28 PM:
--

SOLR-8394_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest 
release
*patch deleted*

Simple test:
http://localhost:8983/solr/all/admin/luke?wt=xml
- without the patch : -1
-- -1 is the default return value !
- fixed by the patch : 299034



was (Author: igiguere):
SOLR-8394_tag_7.5.0.patch : Same patch, on revision 61870, tag 7.5.0, latest 
release
*** patch deleted ***

Simple test:
http://localhost:8983/solr/all/admin/luke?wt=xml
- without the patch : -1
-- -1 is the default return value !
- fixed by the patch : 299034


> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8394:
---
Attachment: (was: SOLR-8394_tag_7.5.0.patch)

> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8394:
---
Attachment: SOLR-8394.patch

> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch, 
> SOLR-8394_tag_7.5.0.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8394) Luke handler doesn't support FilterLeafReader

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088061#comment-17088061
 ] 

Isabelle Giguere commented on SOLR-8394:


New patch, off Git master.  Includes the unit test mentioned in the previous 
comment. 

> Luke handler doesn't support FilterLeafReader
> -
>
> Key: SOLR-8394
> URL: https://issues.apache.org/jira/browse/SOLR-8394
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Molloy
>Priority: Major
> Attachments: SOLR-8394.patch, SOLR-8394.patch, SOLR-8394.patch, 
> SOLR-8394_tag_7.5.0.patch
>
>
> When fetching index information, luke handler only looks at ramBytesUsed for 
> SegmentReader leaves. If these readers are wrapped in FilterLeafReader, no 
> RAM usage is returned.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087774#comment-17087774
 ] 

Isabelle Giguere commented on SOLR-8319:


Patch attached, based on master.  Please read previous comment for details.

> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
>  Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
>   Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I 
> believe the problem is that when my analysis process is applied twice it 
> results in a null query. OK this might be seen as my issue because of dodgy 
> analysis, I thought it might be because I have the wrong order with 
> LengthFilterFactory before EnglishPossessiveFilterFactory and 
> KStemFilterFactory, i.e.:
> 
> 
>  
> So that "cat's" -> "cat" -> "", however any filter order I tried still 
> resulted in a NPE, and perhaps there is a viable case where parsing a term 
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has 
> to undergo any analysis. If the term is from the index can it not simply be 
> created using a TermQuery, which I would imagine would also be faster. I 
> altered the "getFieldQuery" line above to the following and that has fixed my 
> NPE issue.
>   Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use 
> of Solr, rather than actually fixing an issue. 
> o.a.s.c.SolrCore java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> 

[jira] [Updated] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Isabelle Giguere updated SOLR-8319:
---
Attachment: SOLR-8319.patch

> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
>  Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
> Attachments: SOLR-8319.patch
>
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
>   Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I 
> believe the problem is that when my analysis process is applied twice it 
> results in a null query. OK this might be seen as my issue because of dodgy 
> analysis, I thought it might be because I have the wrong order with 
> LengthFilterFactory before EnglishPossessiveFilterFactory and 
> KStemFilterFactory, i.e.:
> 
> 
>  
> So that "cat's" -> "cat" -> "", however any filter order I tried still 
> resulted in a NPE, and perhaps there is a viable case where parsing a term 
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has 
> to undergo any analysis. If the term is from the index can it not simply be 
> created using a TermQuery, which I would imagine would also be faster. I 
> altered the "getFieldQuery" line above to the following and that has fixed my 
> NPE issue.
>   Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use 
> of Solr, rather than actually fixing an issue. 
> o.a.s.c.SolrCore java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> 

[jira] [Commented] (SOLR-8319) NPE when creating pivot

[Isabelle Giguere (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079974#comment-17079974
 ] 

Isabelle Giguere commented on SOLR-8319:


Finding SOLR-8921 resolved gave me hope, I must admit !

However, on code from Solr tag 8.5.0, I found that the suggested fix in the 
description :
org.apache.solr.handler.component.PivotFacetProcessor.getSubset(DocSet, 
SchemaField, String)
{code}
Query query = new TermQuery(new Term(field.getName(), pivotValue));
{code}
Causes NPE in org.apache.solr.handler.component.DistributedFacetPivotLargeTest, 
line 527 (in the test for date-time)
Possibly because range query works better for date-time values ?

Existing code in 
org.apache.solr.handler.component.PivotFacetProcessor.getSubset(DocSet, 
SchemaField, String)
{code}
Query query = ft.getFieldQuery(null, field, pivotValue);
{code}
Calls a method which will try to create a range query (for exact match).  Seems 
enough to save DistributedFacetPivotLargeTest.

Besides my comment on SOLR-8921, regarding stopwords, I haven't found any other 
explanation for the NPE.
https://issues.apache.org/jira/browse/SOLR-8921?focusedCommentId=16657331=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16657331

Personally, for now, I'm still applying the patch from SOLR-8921 ... Not 
because I had something to do with it, but because it doesn't break anything, 
including  org.apache.solr.handler.component.DistributedFacetPivotLargeTest ;)


> NPE when creating pivot
> ---
>
> Key: SOLR-8319
> URL: https://issues.apache.org/jira/browse/SOLR-8319
> Project: Solr
>  Issue Type: Bug
>Reporter: Neil Ireson
>Priority: Major
>
> I get a NPE, the trace is shown at the end.
> The problem seems to be this line in the getSubset method:
>   Query query = ft.getFieldQuery(null, field, pivotValue);
> Which takes a value from the index and then analyses it to create a query. I 
> believe the problem is that when my analysis process is applied twice it 
> results in a null query. OK this might be seen as my issue because of dodgy 
> analysis, I thought it might be because I have the wrong order with 
> LengthFilterFactory before EnglishPossessiveFilterFactory and 
> KStemFilterFactory, i.e.:
> 
> 
>  
> So that "cat's" -> "cat" -> "", however any filter order I tried still 
> resulted in a NPE, and perhaps there is a viable case where parsing a term 
> twice results in a null query.
> The thing is I don't see why when the query term comes from the index it has 
> to undergo any analysis. If the term is from the index can it not simply be 
> created using a TermQuery, which I would imagine would also be faster. I 
> altered the "getFieldQuery" line above to the following and that has fixed my 
> NPE issue.
>   Query query = new TermQuery(new Term(field.getName(), pivotValue));
> So far this hasn't caused any other issues but perhaps that is due to my use 
> of Solr, rather than actually fixing an issue. 
> o.a.s.c.SolrCore java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91)
> at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228)
> at 
> org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
>