[
https://issues.apache.org/jira/browse/KNOX-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890260#comment-15890260
]
Kevin Risden commented on KNOX-841:
-----------------------------------
{quote}
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
{quote}
Don't have a comment for this first item.
{quote}
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.
{quote}
Solr does not have a UI authentication/login form. The Solr UI is just Angular
and really just client side in the browser.
{quote}
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?
{quote}
Solr does not have a UI login page.
{quote}
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?
{quote}
This was just added in Solr 6.4 with SOLR-9324 (released a few weeks ago).
{quote}
c. Does the UI require Kerberos if the API requires Kerberos?
{quote}
Yes the UI requires Kerberos if the API requires Kerberos. The UI doesn't
actually care but all the calls from the browser to the backend would be
kerberized.
{quote}
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?
{quote}
The UI doesn't have a login form. Therefore its not really possible to do
separate authentication.
{quote}
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.
{quote}
The new one should be just plain SOLR if it encompasses both the UI and API.
{quote}
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.
{quote}
I looked into splitting the definition of UI and API into two separate rules a
bit this weekend. I don't think its the right approach since the UI doesn't
have a login form. This means we should have a single SOLR service definition
that handles both.
> 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)
