lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: SolrDispatchFilter and /prefixed request handlers
Date Thu, 18 Jun 2009 18:13:30 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.
>
> that's my understanding ... but i don't have a strong opinion about
> leaving it or changing it.

Yeah, I can buy that rationale a bit.  I don't think it's compelling  
enough to leave as-is though, given the benefits of allowing /select  
to work with any request handler.

Is there a way to disable /select altogether and simply only allow  
defined request handlers?  Even if not, security-wise it could be  
noted that blocking /select externally somehow is recommended if you  
want precise control over Solr request handler paths.

> It seems like it might be just as useful to kill all knowledge of "qt"
> from SolrDispatchFilter, and move that functionality to a
> "DelegatingRequestHandler" that people could register as "/select"  
> if they
> want the legacy behavior.  (which would simplify SolrDispatchFilter  
> in the
> common case)

But I'm as much or more of a URL purist as the next guy, and, yeah,  
SolrDispatchFilter is definitely up for refactoring.  It's one place  
that folks have to override/replace when embedding Solr into a  
custom .war file.

If there are no objections, I'll commit this change tomorrow (along  
with SOLR-1230).

	Erik



Mime
View raw message