You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Larry McCay (JIRA)" <ji...@apache.org> on 2017/05/11 19:25:04 UTC
[jira] [Comment Edited] (KNOX-924) X-forwarded-host,
X-forwared-port header behavior when there are multiple balancers/proxys
causing redirection problems
[ https://issues.apache.org/jira/browse/KNOX-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007035#comment-16007035 ]
Larry McCay edited comment on KNOX-924 at 5/11/17 7:24 PM:
-----------------------------------------------------------
[~jeffreyr97] - I am really trying to get my head around this but am somehow having trouble.
I think that I need a sequence diagram to understand the problem here.
{noformat}
browser appserver proxy knox
| | | |
|-------------->| | |
| |-------------->| |
| | |--------->|
| | | |
| |<--------------|-----------|
{noformat}
1. browser to application
2. appserver to knox via proxy
3. proxy sets X-Forward headers so that Knox knows the actual client rather than the proxy
4. knox namenode redirects the POST or PUT to the datanode and knox rewrites Location header via X-Forward headers to the actual client in this case the appserver
It seems to me that we may still need the X-Forward header support in order to have the Location header reflect the proxy instead of a knox instance itself. Presumably, the appserver doesn't have actual line of sight of the Knox instances and has to go through the proxy. This is why this support was added in the first place.
I'm going to have to try and reproduce this and verify whether my statements hold up though.
was (Author: lmccay):
[~jeffreyr97] - I am really trying to get my head around this but am somehow having trouble.
I think that I need a sequence diagram to understand the problem here.
{code}
browser appserver proxy knox
| | | |
|-------------->| | |
| |-------------->| |
| | |--------->|
| | | |
| |<--------------|-----------|
{code}
1. browser to application
2. appserver to knox via proxy
3. proxy sets X-Forward headers so that Knox knows the actual client rather than the proxy
4. knox namenode redirects the POST or PUT to the datanode and knox rewrites Location header via X-Forward headers to the actual client in this case the appserver
It seems to me that we may still need the X-Forward header support in order to have the Location header reflect the proxy instead of a knox instance itself. Presumably, the appserver doesn't have actual line of sight of the Knox instances and has to go through the proxy. This is why this support was added in the first place.
I'm going to have to try and reproduce this and verify whether my statements hold up though.
> X-forwarded-host, X-forwared-port header behavior when there are multiple balancers/proxys causing redirection problems
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-924
> URL: https://issues.apache.org/jira/browse/KNOX-924
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Jeffrey E Rodriguez
> Assignee: Jeffrey E Rodriguez
> Priority: Critical
>
> When there are other intermediaries between client and Knox it is possible to cause Knox rewrites to not go to the gateway host but in fact the gateway.host reflects X-forwar-host.
> e.g.
> "curl -v -k -u guest:guest-password -H X-Forwarded-Proto: http -H X-Forwarded-For: jeff -H X-Forwarded-Context:/ordexecvalid-prod/data/ -H X-Forwarded-Port: 843 -H X-Forwarded-Host: myfoo.com -i https://knox1.fyre.ibm.com:8443/gateway/default/webhdfs/v1/apps/hbase/data/hbase.id?op=OPEN
> * Trying 9.30.57.135...
> * TCP_NODELAY set
> * Connected to knox1.fyre.ibm.com (9.30.57.135) port 8443 (#0)
> * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate: localhost
> * Server auth using Basic with user 'guest'
> > GET /gateway/default/webhdfs/v1//iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?op=OPEN HTTP/1.1
> > Host: knox1.fyre.ibm.com:8443
> > Authorization: Basic Z3Vlc3Q6Z3Vlc3QtcGFzc3dvcmQ=
> > User-Agent: curl/7.51.0
> > Accept: */*
> > X-Forwarded-Proto: http
> > X-Forwarded-Server: myfooserver.com
> > X-Forwarded-For: jeff
> > X-Forwarded-Context: /ordexecvalid-prod/data/
> > X-Forwarded-Port: 843
> > X-Forwarded-Host: myfoo.com
> < HTTP/1.1 307 Temporary Redirect
> HTTP/1.1 307 Temporary Redirect
> < Date: Sun, 16 Apr 2017 00:18:44 GMT
> Date: Sun, 16 Apr 2017 00:18:44 GMT
> < Set-Cookie: JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> Set-Cookie: JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> < Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> < Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0; Expires=Sat, 15-Apr-2017 00:18:44 GMT
> Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0; Expires=Sat, 15-Apr-2017 00:18:44 GMT
> < Cache-Control: no-cache
> Cache-Control: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Location: http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> Location: http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> < Content-Type: application/octet-stream
> Content-Type: application/octet-stream
> < Server: Jetty(6.1.26-ibm)
> Server: Jetty(6.1.26-ibm)
> < Content-Length: 0
> Content-Length: 0
> See here the redirection header.
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> This could cause unexpected results.
> The UrlRequestResponse would use the X-Forward headers (even if gateway.xforwarded.enabled is false).
> The documentation is very succinct. It seems like the xforwarded.enabled only accomplish passing the "Knox" x-Forward-* headers when it is not set to false.
> But there is no documentation on the effect of other servers setting up X-Forward header between client and Knox.
> I could even inject an X-Forward-* header and have Knox to redirect to a different server than the one original Knox. See my relocation URL
> Location: http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-
> This behavior seems very confusing.
> 1. It should ok to pass multiple X-Forwarded-Host through.
> 2. It is unexpected that Knox should use X-Forward-Host and X-Forwarded-Port as the Gateway host and port. e.g. {gateway.host} and {gateway.port} would reflect the value of X-Forwarded-Host and X-Forwarded-Port. This doesn't seem to leave any other options to rewrite rules which don't want to use X-Forwarded-Host.
> 3. The rewrite feature of Gateway doesn't seem to work well with X-Forward* feature.
> 4. X-Forward* feature in gateway is not well documented. The extend of the documentation is a description of the filter that adds X-Forward headers to Knox. We may need to explain whot X-forward headers affect Knox behavior.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)