[
https://issues.apache.org/jira/browse/KNOX-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890117#comment-15890117
]
Larry McCay commented on KNOX-841:
----------------------------------
As I compare this patch to the existing service definition for the API only,
there are a number of questions that come to mind regarding both definitions. I
feel as though we are going to have to push this out of 0.12.0 unless all of
them are already addressed and can be articulated clearly.
1. The existing service definition includes explicit provider definition which
is generally not needed for APIs unless they have some specific reason to
reorder them or require a specific provider by name
2. The existing service definition declares the use of a specific dispatch
implementation that simply passes all headers to the backend service. This is
not likely to support the trusted proxy pattern used in Hadoop for
impersonation, etc unless we rely on the client to set the proper things which
leaves it open for spoofing identities. This is generally only done for UIs
that provide their own authentication/login forms like Ambari, Ranger, etc.
3.This patch combines the UI and API into a single definition. While the URL
pattern of the UI and API are not sufficiently separate with typical API
contexts, there are probably reasons to separate them. For instance:
a. Does the Solr UI have a login page or some other reason to require a
different dispatch provider than the API?
b. Does the Solr UI *and* API both implement the trusted proxy pattern from
Hadoop such that Knox will authenticate via SPNEGO/kerberos as Knox but
propagate the authenticated user via doAs parameter?
c. Does the UI require Kerberos if the API requires Kerberos?
d. Is there a reason to be able to expose the API with HTTP basic
authentication while the UI needs to use a login form?
4. If we were to commit this patch, is there any reason to not just make it a
new version of the existing definition? They both use the route path "solr" in
the URL. One just happens to have a much narrower definition that is limited to
the API. I would suggest that we move it into the same solr directory as a new
version and a different role name. The current one is SOLRAPI. We can make the
new one just plain SOLR and it can encompass both UI and API - *if all of the
above concerns are satisfied*.
5. If the above concerns cannot be satisfied currently then we should consider
what it will mean to split the UI and API into separate definitions. I suspect
we would want to fix various things about the current SOLRAPI definition and
use that as the API def and add a new SOLRUI definition which this patch would
morph into.
Again, I feel that there are likely too many unknowns above that need
investigation to keep this in 0.12.0 but I may be mistaken.
If we do move this patch out then we need to test some of the concerns above
regarding the current SOLRAPI definition.
Thoughts?
> Proxy support for Solr UI
> -------------------------
>
> Key: KNOX-841
> URL: https://issues.apache.org/jira/browse/KNOX-841
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Affects Versions: 0.10.0
> Reporter: Richard Ding
> Assignee: Richard Ding
> Fix For: 0.12.0
>
> Attachments: KNOX_841_1.patch, KNOX-841_2.patch, KNOX_841.patch,
> Screen Shot 2017-02-05 at 3.01.20 PM.png
>
>
> Provide proxy UI support for the Solr UI.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
