[jira] [Commented] (KNOX-841) Proxy support for Solr UI

["Larry McCay (JIRA)" <ji...@apache.org>]

    [ 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)