lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: SolrDispatchFilter and /prefixed request handlers
Date Fri, 19 Jun 2009 13:58:24 GMT

On Jun 18, 2009, at 12:56 PM, Chris Hostetter wrote:

> : Why might this bit of code in SolrDispatchFilter be useful?
> :
> :               if( qt != null && qt.startsWith( "/" ) ) {
> :                 throw new  
> SolrException( SolrException.ErrorCode.BAD_REQUEST,
> : "Invalid query type.  Do not use /select to access: "+qt);
> :               }
> I believe it was intended as a "security" aid when the new path style
> handler names were introduced.  the idea was that "qt" was going to be
> deprecated, and as new solradmins configure solr ports with path style
> handler names, they might (reasonably) expect that enabling path based
> authentication/filters in their servlet containers would help protect
> those -- this bit of code prevents users from bypassing security of  
> that
> type by exploiting legacy behavior.

I tried adding the blurb below to 
, but the Solr wiki has some issues ("Page could not get locked.  
Missing 'current' file?") with me saving.


== Request Handler Paths ==

Solr provides access to request handlers through a general purpose / 
select?qt=request_handler_name URL.  Prior to ["Solr1.4"] (via  
SOLR-1233), request handlers named with a leading forward-slash like / 
select?qt=/request_handler_name could not be used, but had to be  
requested using /request_handler_name.  ["Solr1.4"] removes the  
forward-slash restriction and allows /select to work with any request  
handler name.  Externally blocking access to /select is recommended in  
environments where only path-based access to request handlers is  

View raw message