[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027583#comment-16027583
]
Larry McCay commented on KNOX-751:
--
[~jeffreyr97] - Sorry for the delay in getting this reviewed and committed.
I've just committed this to master and it will be available in 0.13.0.
Thank you for the contribution!
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-751.001.patch
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027582#comment-16027582
]
ASF subversion and git services commented on KNOX-751:
--
Commit e4768f1efce860099c6a1f8d366e2a58954c0314 in knox's branch
refs/heads/master from [~lmccay]
[ https://git-wip-us.apache.org/repos/asf?p=knox.git;h=e4768f1 ]
KNOX-751 - Need rewrite function to capture href information from single page
host to rewrite output of node hosts (Jeffrey E Rodriguez via lmccay)
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-751.001.patch
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15946455#comment-15946455
]
Larry McCay commented on KNOX-751:
--
Thanks, [~jeffreyr97] - we will certainly review.
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.13.0
>
> Attachments: KNOX-751.001.patch
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942881#comment-15942881
]
Jeffrey E Rodriguez commented on KNOX-751:
---
Was revisiting this again.
An example can illustrate what is that we need.
HDFS UI now has links to DataNode UI servers, each DataNode server has its own
hostname.
For Knox to map to rewrite to multiple host of the same type (as above the
DataNode UI, we have to options.
DATANODE
http://foo:50075
1. Create different topology files. datanode1.xml datanode2.xml datanode3.xml
datanodeN.xml
Each one of the new topologies can map a unique datanode host per topology.
The only issue here is that the URL path would change since topology name
reflect the name of topology file.
e.g.
http://knox_url:knox_port:/gateway/datanode1
http://knox_url:knox_port:/gateway/datanode2
...
2. Another way to accomplish this is by passing the datanode URL as a query
parameter and attaching this parameter as
an OUTPUT rewrite.
e.g.
I am able to get the hostname information and dispatch to a datanode hostname
but we needed to add an OUTPUT rule (content rewrite) so we can attach the
hostname parameter to the hrefs on the content.
I've created an OUTPUT rewrite function which can access the input request
parameters.
An example of a rule would be:
{code:xml}
...
...
{code}
Which can then be forward to a dispatcher with
{code:xml}
...
{code
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.13.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883902#comment-15883902
]
Larry McCay commented on KNOX-751:
--
Moving to 0.13.0.
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.13.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880981#comment-15880981
]
Sumit Gupta commented on KNOX-751:
--
[~jeffreyr97], as we are trying to close down 0.12.0 I wanted to know if you
are going to provide a patch for this or should this be moved out to 0.13.0?
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.12.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596211#comment-15596211
]
Larry McCay commented on KNOX-751:
--
[~jeffreyr97] - I am starting the process of closing down on 0.10.0 and
deferring open issues out to 0.11.0 or or Future. If you plan to provide a
patch, please do so in the next couple days. Otherwise, I will probably move
this out to 0.11.0.
Thanks!
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.10.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467964#comment-15467964
]
Jeffrey E Rodriguez commented on KNOX-751:
---
Hi Larry, yes we plan to contribute a patch.
The Yarn UI is already leaking the host:port in the current mapping without
this function but we can obfuscate the URL ("encrypt) it. Internally we can
reversion the obfuscation.
So in the page itself Yarn shows the table of Node Http Address without
"encryption".
e.g.
{code:xml}
bdavm521.svl.ibm.com:8042
{code}
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.10.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KNOX-751) Need rewrite function to capture href information from single page host to rewrite output of node hosts
[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467937#comment-15467937
]
Larry McCay commented on KNOX-751:
--
[~jeffreyr97] - This seems interesting - do you plan to contribute a patch?
I'm wondering whether this will leak host:port information of the backend
applications or if this will be protected by our existing URL encryption.
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> ---
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
>Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
>Reporter: Jeffrey E Rodriguez
>Assignee: Jeffrey E Rodriguez
> Fix For: 0.10.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
>
>
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
