[
https://issues.apache.org/jira/browse/SOLR-18537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136782#comment-18136782
]
Nick Shanin commented on SOLR-18537:
------------------------------------
[~epugh] I took a stab at scoping this, and tried the first pieces. [~dsmiley],
your note settles the direction; this is support for that plan rather than
another proposal.
*On the security side:* the tests that shipped with the filter already cover
the authorization change. At the merged head ({{439b2e5096f}}),
{{NodeTargetProxyFilterTest}} passes 14 of 14 and
{{NodeTargetProxyFilterAuthTest}} 4 of 4. The auth test's cluster is the
standard secured shape, with PKI handling inter-node signing, and it proves the
target node authorizes the caller rather than the proxying node. Today's
{{nodes}} fan-out does the opposite: the caller is authorized once, and the
proxied requests then present the node's own identity, so receiving nodes run
no authorization at all. Moving callers to the header mechanism closes that
widening; the one visible consequence is that a multi-node action can now
partially apply, with per-node failures, where the fan-out hid them.
*For the deprecation, the full set:* the {{nodes}} handling lives in
{{LoggingHandler}}, {{SystemInfoHandler}}, {{MetricsHandler}} (shared with the
v2 {{GetMetrics}}), {{GetNodeSystemInfo}}, and {{NodeLogging}}, all through the
{{handler/admin/proxy}} package ({{RemoteRequestProxy}},
{{GenericV1RequestProxy}}, {{V2SolrRequestBasedProxy}}; 348 lines plus three
test classes). The param is also declared on the v2 APIs in the {{solr/api}}
module, so it is part of the generated SolrJ client surface.
{{MetricsHandler}}'s single-node {{node}} param rides the same machinery.
*The admin UI shift, tried:* on a local branch against the merged head (not
pushed), the metrics resource sends {{X-Solr-targetNode}} as its GET param in
place of {{node}}; the Nodes view fetches system info once per node with the
proxy header; the logging page lists live nodes and issues one proxied PUT per
node in cloud mode, keeping the local call in standalone mode. The files are
{{services.js}}, {{controllers/cloud.js}}, and {{controllers/logging.js}}.
Syntax-checked only; there is no JS test harness for these controllers, so the
slice still wants a live UI pass before it counts as done. Happy to open that
as its own PR if the split works for you both, or hand the diff over if you
would rather fold it into the deprecation work.
🤖 _AI text above_ 🤖 _(reviewed by Nick Shanin)_
> Proxy to any user-specified SolrCloud node by header/param
> ----------------------------------------------------------
>
> Key: SOLR-18537
> URL: https://issues.apache.org/jira/browse/SOLR-18537
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Attachments: response.md
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> It can be very useful for Solr to proxy requests to another node, specified
> in a header or param. Â The intended scenario is when there's an HTTP proxy in
> front of Solr, and the backing Solr nodes aren't directly reachable. Â Solr is
> doing that now for a few admin endpoints that have already been coded for it,
> using {{GenericV1RequestProxy}} internally (e.g. for logging, info, ...). Â
> The issue here instead proposes a generic mechanism that doesn't require Solr
> handlers to be coded any differently.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
