[
https://issues.apache.org/jira/browse/SOLR-17266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842779#comment-17842779
]
Gus Heck commented on SOLR-17266:
---------------------------------
The ultimate way to improve this (ignoring effort momentarily) is to move all
the admin stuff into a separate servlet. This should be possible (though by no
means trivial) now that the CoreContainer is started in a
ServletContextListener and guaranteed to run before any servlet or servlet
filter code.
The nifty bit of that would be turning a bunch of stuff into filters that can
wrap any servlet (like Auth, tracing, etc) and making DispatchFilter even
skinnier...
In theory, there's very little reason for adminV1/adminV2/admire query/update
to all be living in the same ServletFitter nor for such a wide variety of
wrapping behaviors to all be packed into one big fitter.
Ideally:
* */* = ({color:#de350b}context{color}{color:#172b4d}){color} static login
page, not wrapped/controlled by security.json based auth (no fancy tricks
needed to expose no risk that anything else is exposed, not even any exposure
of the angular application css/scripts/etc)
* */solr* = {color:#de350b}context{color} for functionality that needs a
CoreContainer
* */solr/api* = v2api (servlet)
* */solr/query* = querying via query params (servlet)
* */solr/jsonq* = querying via json request bodies (servlet)
* */solr/streaming* = code path for streaming stuff (servlet)
* */solr/update* = code paths for sending data to solr (servlet)
* */solr/v1* = legacy get request based api. (servlet)
* */solr/nextApiSomeonDreamsUp* = next way of interacting with admin functions
(or query!) (servlet)
* */admin* = the {color:#de350b}context{color} hosting the angular.js UI
* */amazingUI* = the {color:#de350b}context{color} hosting the next ui
framework or whatever.
There are likely other things that deserve their own servlet... I imagine that
this could be picked apart bit by bit, and once established, new bits could
land in their own locations.
If each context was distributed as a .war, the angular Ul could be uninstalled
by folks looking to customize their deployments and make them skinny (or maybe
even deployed to an entirely separate server?). Other power users could choose
not wrap query in authentication if they don't care about read access buy still
have an auth filter around only admin/update stuff or pick and choose which
areas are wrapped with tracing support ... etc... This type of structure would
mean that adding new ways to access things does not require adding
branching/logic/complexity, to the previously existing ways of accessing
solr... (as we do now).
Of note here is that things like /solr/query and /solr/jsonq or various flavors
of admin apis would become thin wrappers merely translating input formats into
identical java objects then handled by the same internal code paths... obtained
from CoreContainer, which can be obtained by any servlet in the same way our
current ServletFilter obtains it..
> Investigate avoiding Jetty "____v2" path rewrite
> ------------------------------------------------
>
> Key: SOLR-17266
> URL: https://issues.apache.org/jira/browse/SOLR-17266
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Minor
>
> Users of Solr's v2 API submit requests whose paths start with "/api".
> Internally however, these paths are rewritten by a Jetty pre-filter to
> instead start with "/solr/____v2". This was done in SOLR-8045 as a way to
> provide distinct user-facing URLs while still keeping all requests within a
> single servlet that Solr offers at "/solr".
> While this is invisible to users in the majority of cases, it does find ways
> to periodically leak out. In particular it can surprise plugin writers who
> find that the path referenced in their SolrQueryRequest or HttpServletRequest
> object looks very different from what they'd expect.
> We should see if there's a cleaner way to implement this, that avoids this
> pitfall.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
