Hi Sergii,
Thanks for approving the proposal.
The change is fine, except for two issues:
1. It does not conform to the IETF standard and tolerates invalid X-Forwarded-Host values.
http://tools.ietf.org/html/rfc7230#section-5.4
2. When building the URI, port 80 is always considered a default port although it is for HTTP only (not HTTPS).
I made an additional pull request on Andrey's dedicated branch with fixes, logging and additional testing. Please review:
www.github.com/codenvy/everrest/pull/6
thank you
Tareq Sharafy
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Friday 05 June 2015 11:44
To: che developer discussions
Cc: Sharav, Omer
Subject: Re: [che-dev] Forwarding headers in Everret and HATEOAS
Everrest technical committee approved your way.
AFAIK it's based on your PR. Plz review it. Any feedback are welcome.
We are waiting to add X-Forwarded-Proto functionality. And when we will be ready to merge it in master.
On Thu, Jun 4, 2015 at 5:05 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
My answer I will base on such facts:
1. None of known to me REST implementation has nothing to do with x-forwarded-host, x-forwarded-port, x-forwarded-proto
2. A lot of our sorce code relay on
servletRequest.getScheme()
servletRequest.getServerName()
servletRequest.getServerPort()
HttpServletRequest.getRequestURI
It means that fix in Everrest will be only part of work and we will need to fix something else.
We most confident way for me is to explain Servlet container to which schema, port and server name current request belong to.
It can be Valve or Filter before EverrestServlet.
On Thu, Jun 4, 2015 at 5:02 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi all,
I've made a fix proposal in Everrest that makes ServletContainerRequest aware of the X-Forwarded-Host.
The fix was made according to the IETF standard http://tools.ietf.org/html/rfc7239,
tests included.
Please review the pull request
www.github.com/codenvy/everrest/pull/5
thank you
Tareq Sharafy
Hi,
Sure. Here are example request headers I send to Che:
x-forwarded-host: localhost:5000
x-forwarded-port: 5000
x-forwarded-proto: http
x-forwarded-for: ::1
The Che server itself is installed on another machine on the network, e.g.
10.0.0.20:8080. I send following request:
GET http://10.0.0.20:8080/api/workspace/1q2w3e
This is an example link that I get in the response:
{ "rel": "get projects", "href": "http://10.0.0.20:8080/api/project/1q2w3e", … }
Although this is the link I would like to get:
{ "rel": "get projects", "href": "http:// localhost:5000/api/project/1q2w3e", … }
Or whatever passed in the x-forwarded-host header.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Wednesday 03 June 2015 15:54
To: che developer discussions
Subject: Re: [che-dev] Forwarding headers in Everret and HATEOAS
Can you provide more information about request you are making, response you receiving and what you expect?
On Wed, Jun 3, 2015 at 3:50 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi Sergii,
Thanks for the help.
I've tried your valve-based solution with your suggestion. It does affect the remote address that
is reported by the underlying HTTP servlet as expected, but still this doesn't solve the issue I described because everrest's servlet container ignores this information. The HATEAOS links that Che builds depend on the URIs reported by Che. A fix should be
applied at Everrest or Che levels. Please assist if you have a different conclusion regarding this point.
As I suggested earlier, I can narrow the scope of the fix by modifying ServiceContextImpl only.
thank you
Tareq Sharafy
From:
che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergii Kabashniuk
Sent: Wednesday 03 June 2015 12:57
To: che developer discussions
Subject: Re: [che-dev] Forwarding headers in Everret and HATEOAS
We have expirience the same problem after we setup haproxy (as reverse proxy) and set up https.
Solution for this is following
On haproxy side we added X-Forwarded-Proto header
On tomcat we added to server.xml
<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="X-Forwarded-Proto"
internalProxies="Proxy IP here"/>
When Everest start making correct links because after that tomcat correctly answer HttpRequest.isSecure()
On Wed, Jun 3, 2015 at 12:43 PM, Sharafy, Tareq <tareq.sharafy@xxxxxxx> wrote:
Hi,
We're trying to deploy Che-based servers on a landscape that dispatched requests through reverse proxies. The de-facto standard
forwarding headers are used:
X-Forwarded-Host
X-Forwarded-Port
X-Forwarded-Proto
We noticed that the HATEAOS links that are returned by Che are incorrect and are narrowly based on the direct URLs of the requests
that the server receives, which are the internal proxy-to-Che URLs in this case. Further inspection show that that root cause is that Everrest constructs request object objects (org.everrest.core.servlet.ServletContainerRequest) without taking the forwarding
headers into account.
Our proposal is to contribute a code fix in everrest that takes the forwarding headers into account when construct the URLs.
An alternative is make a higher-level change, e.g. at ServiceContextImpl (inside che-core-api).
Can you please provide insights? Is the current behavior intentional for some reason?
thank you
Tareq Sharafy
Cloud Development Experience | SAP Labs Israel | 15 Hatidhar st, Raanana 43665, Israel
T +972-(0)7-4732-1647
| F +972-(0)9-777-5618
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
|
