some thoughts inline...
On Mon, Dec 6, 2021 at 2:04 PM Noble Paul <noble.p...@gmail.com> wrote:
> I'm +1 for modernization
> I just wanted to highlight the hurdles we need to overcome to reach there
>
> SolrRequestHandler is the current framework that serves all requests in
> Solr. This also has associated ways to
>
> - register end points and configuration
>
> The way we construct our URL's makes this a bit difficult since they are
written /context/object/action rather than context/action/object. If
designed from scratch, /context/action/object would have been be preferable
because the ation would naturally map to a servlet or other service and the
path-info to the thing to act on. This ancient design decision is a hurdle
for applying filters (due to the limited pattens afforded by servlet spec
12.2) with specificity, and for any alternative implementations to mimic.
>
> - manage lifecycle
>
> Most frameworks and certainly every servlet/filter/listener has a built in
lifecycle that we should leverage.
>
> - collect metrics
>
> I haven't looked but I expect there's some need to connect the request
thread with the metrics system and clear out the association upon request
completion, likely a job for a Servlet filter, which could then wrap any of
our services.
>
> - enforce security
>
> Security probably ought to have a few parts:
- Authentication should be standardized to a servlet filter that can be
wrapped around any of our services however they are implemented. The filter
would be in charge of populating a principal, and connecting it with a
system to apply roles from which permissions can be calculated (and
appropriately cache this information in the session so we don't calculate
it on every request... unless there is a use case for permission updates
faster than session expiration, but I suggest not, or at least not by
default).
- A filter inside of (after) the authn filter that checks authz for path
based permissions, possibly also inspectint the request parameters and/or
payload to calculate things like collection or handler and verify that the
user has the required permission. Note that there might be several such
filters, possibly one inferring read/write/update/delete from the request
method, that only wraps API's that consistently utilize http verbs... or
whatever
- In some cases explicit checks in code at critical points to guard
specific functionality might be required, a good security framework will
allow this too. i.e. if (SecurityUtils.getSubject().isPermitted(permission))
{ /* do stuff */ } else { throw AuthzException("or whatever") }
> - logging
>
> MDC context setup/teardown per request for logging should be a Servlet
Filter wrapping any of our services running in jetty.
>
> - tracing
>
> Also a candidate for a servlet filter that can wrap any of our services
>
> - etc etc
>
> The more of this stuff we can extract from SolrDispatchServlet and into
independent filters, the easier it is to just wrap JAX-RS or other new
technologies (assuming we aren't targeting async requests in JAX-RS wherein
things get a bit more complicated.) The fact we have lots of servlet
related code and run inside a servlet container (jetty) means we should be
biased towards JAX-RS implementations that are based on servlets (I think
Jersey is one, quick googling indicates there is a Jersey-Servlet class )
> Introducing a new framework will have to deal with all of the above. For
> instance the JAX-RS is used you will start using web.xml to register your
> JAX-RS endpoints.
>
> --Noble
>
>
