lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koorosh Vakhshoori <Koorosh.Vakhsho...@synopsys.com>
Subject RE: Any option to NOT return stack trace in Solr response?
Date Fri, 22 Jul 2016 23:09:16 GMT
Hi Alex,
  Thanks for confirming my finding.

  When it comes to Solr interfacing to a client, I agree completely.  However, I was hoping
to limit the noise at Solr and not have to add extra code to filter out the exceptions. Just
wondering, wouldn't it be a cleaner RESTFUL interface if instead of reporting the stack trace
in response, Solr would return an error code and a basic message pointing back to Solr log
for details such as stack trace. I am curious, what use case would it serve where one would
require the stack trace in response?

  If there is interest, I could open an JIRA and come up with a patch.

Regards,

Koorosh

-----Original Message-----
From: Alexandre Rafalovitch [mailto:arafalov@gmail.com] 
Sent: Thursday, July 21, 2016 6:54 PM
To: solr-user <solr-user@lucene.apache.org>
Subject: Re: Any option to NOT return stack trace in Solr response?

I don't think there is a flag.

But the bigger question is whether you are exposing Solr directly to the client? You should
not be. You should have a middleware client that talks to Solr and then generates web UI or
whatever.

If you give untrusted access to Solr, there are too many things that can be done, starting
from deleting the whole index.

It might be possible to have a smart proxy and expose Solr with heavily filtered valid URLs,
then you would need to scrub response.

That's all I can think of without hacking and reregistering with your own response handler
(probably not that hard).

Regards,
    Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 22 July 2016 at 03:35, Koorosh Vakhshoori <Koorosh.Vakhshoori@synopsys.com> wrote:
> Hi all,
>   Got a Solr 5.2.1 installation. I am getting following error response when calling the
TERMS component. Now the error is not the point, I know what is going on in this instance.
However, to address security concerns, I am trying to have Solr truncate the stack trace in
the response. Of course I would still want Solr to log the error in its log file. What I was
wondering, if there is a flag or option I can set in solrconfig.xml globally or under TERMS
to omit the trace or just return ' java.lang.NullPointerException'? I have looked at the source
code and don't see anything relevant. However, I may have missed something. Appreciated any
suggestion and pointers.
>
> <response>
> <lst name="responseHeader">
> <int name="status">500</int>
> <int name="QTime">5</int>
> </lst>
> <lst name="error">
> <str name="trace">
> java.lang.NullPointerException at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(Sear
> chHandler.java:322) at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandle
> rBase.java:143) at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2067) at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654) at 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450) at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter
> .java:227) at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter
> .java:196) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:239) at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:206) at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:239) at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:206) at 
> org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:4
> 39) at 
> org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:178) 
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:239) at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:206) at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> lve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
> </str>
> <int name="code">500</int>
> </lst>
> </response>
>
> Regards,
>
> Koorosh
Mime
View raw message