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
