[
https://issues.apache.org/jira/browse/KNOX-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14633101#comment-14633101
]
Yu Gao commented on KNOX-565:
-----------------------------
Thanks Kevin for your comment!
I figured this out from Knox user and dev guide and also Knox source code. The
rest services code had given a good example and explanation of how knox works,
and from there I started to dig into and learn the whole rewrite framework.
1. Yes I intended to make the javescript rewrite method - filterJavaScript(...)
- reusable by both HtmlFilterReaderBase and JavaScriptFilterReader which
unfortunately already extend from java.io.Reader. A better alternative may be
to have them implement a parent interface which declares filterValueString
method, and put filterJavaScript method in UrlRewriteUtil which will be called
by the two filter readers.
2. You are right. There are no direct UTs for UrlRewriteReaderBase, but the
functionality of its static method filterJavaScript is actually tested out via
HtmlFilterReaderBaseTest and JavaScriptFilterReaderTest, when doing javascript
content rewrite.
3. Yes. Will take a look at how this class does the service testing for REST
and will do the same for UIs.
4. I ran the whole UTs on the latest trunk with the patch applied, and they
passed in my environment. Which unit tests failed in your case? I will attach
the UT result in case I missed anything.
Looks like KNOX-476 is the one introducing X-Forwarded-* headers, including
X-Forwarded-Context, with which Knox can better work with load balancers.
Hopefully backend services can also be improved to respect these headers. Here
is my understanding of this issue and please correct me if I'm wrong:
1). For Knox, it honors the X-Forwarded-* headers in the requests passed to it,
and gateway parameter functions have also taken them into consideration (except
for X-Forwarded-Context for now but this can be made available as well), so
similar to REST rules, the UI rules are general enough and the OUT URLs Knox
returns back, to load balancer for example, retain those information once
passed in.
2). For backend servers, if they could respect the X-Forwarded headers when
generating fully qualified URLs, most of the rewrite rules will not be needed
any more ( the same applies to REST case). Absolute path without scheme and
authority in service response is the scenario that we need to think about, as
the path may be prefixed with extra contexts.
In current patch, the UI of service like hbase has namespace collision with its
REST, which I think I should adjust otherwise the service UI and REST cannot
sit in the same topology file.
> Supporting All the Quick Links on Ambari Dashboard to Go Through Knox
> ---------------------------------------------------------------------
>
> Key: KNOX-565
> URL: https://issues.apache.org/jira/browse/KNOX-565
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Affects Versions: 0.7.0
> Reporter: Tanping Wang
> Fix For: 0.7.0
>
> Attachments: KNOX-565 - UI support design.pdf, KNOX-565-001.patch
>
>
> Today Knox supports authentication and service level authorization for rest
> APIs. We have a need to have all of the user interfaces to also go through
> Knox. So that Knox can become the single hub for all https communications
> including both UIs and rest calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
