Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for port before setting Origin header for watch requests. #1669

Merged
merged 3 commits into from
Aug 1, 2019

Conversation

kjcjohnson
Copy link
Contributor

@kjcjohnson kjcjohnson commented Jul 27, 2019

When the Kubernetes URL used doesn't specify a port
(e.g., https://example.com/api/v1/...), the origin header for
watch requests ends up with a port of -1 (e.g., https://example.com:-1).
This happens because calling getPort() on a java.net.URL object that
does not have a port explicitly specified will always return -1. The
return value was always just inserted into the origin header.

Now, we check for this and only append a port to the origin header if
getPort() returns something other than -1. We make this change in both
the WatchConnectionManager and WatchHTTPManager classes.

I wasn't able to come up with a way to make a test for this, because the
mock Kubernetes server doesn't support specifying the port, and especially not
the defaults of 80/443.

Fixes #1667

 When the Kubernetes URL used doesn't specify a port
(e.g., https://example.com/api/v1/...), the origin header for
watch requests ends up with a port of -1 (e.g. https://example.com:-1).
This happens because calling `getPort()` on a java.net.URL object that
does not have a port explicitly specified will always return -1. The
return value was always just inserted into the origin header.

Now, we check for this and only append a port to the origin header if
`getPort()` returns something other than -1. We make this change in both
the WatchConnectionManager and WatchHTTPManager classes.
@centos-ci
Copy link

Can one of the admins verify this patch?

@gastaldi
Copy link
Contributor

Ok to test

@rohanKanojia
Copy link
Member

ok to test

@cjellick
Copy link

cjellick commented Aug 1, 2019

Do we need an origin header at all? That’s really just useful for protecting browsers from cross site scripting.

Could we simply drop the header all together?

@rohanKanojia
Copy link
Member

@kjcjohnson: Could you please test your patch without header? If it's not breaking anything then let's drop it.

@kjcjohnson
Copy link
Contributor Author

It looks like dropping the origin header won't work. I took some Wireshark captures of the packets, and they're identical other than the Origin header, but only the request with the header succeeds:

Without Origin header:

GET /k8s/clusters/c-scffx/api/v1/namespaces/test-ns/pods?fieldSelector=metadata.name%3Dtestpod-1sntr&watch=true HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: 1Ass6sr+wPqYyEddMR7FPQ==
Sec-WebSocket-Version: 13
Authorization: Bearer <token>
Host: rancher.example.com
Accept-Encoding: gzip
User-Agent: okhttp/3.12.0

HTTP/1.1 403 Forbidden
X-Powered-By: ARR/3.0
X-Powered-By: ASP.NET
Date: Thu, 01 Aug 2019 19:00:43 GMT
Content-Length: 0

With Origin header:

GET /k8s/clusters/c-scffx/api/v1/namespaces/test-ns/pods?fieldSelector=metadata.name%3Dtestpod-rfw80&watch=true HTTP/1.1
Origin: http://rancher.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: zmA6ry8uoV5uumoYhh8rCg==
Sec-WebSocket-Version: 13
Authorization: Bearer <token>
Host: rancher.example.com
Accept-Encoding: gzip
User-Agent: okhttp/3.12.0

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Sec-WebSocket-Accept: WcnYoYGI9IQ0piiOUMVaDwgV1OU=
X-Powered-By: ARR/3.0
Connection: Upgrade
X-Powered-By: ASP.NET
Date: Thu, 01 Aug 2019 19:25:45 GMT

CHANGELOG.md Outdated Show resolved Hide resolved
Co-Authored-By: George Gastaldi <gegastaldi@gmail.com>
@gastaldi
Copy link
Contributor

gastaldi commented Aug 1, 2019

[merge]

@fusesource-ci fusesource-ci merged commit aaeb24f into fabric8io:master Aug 1, 2019
@fusesource-ci
Copy link
Contributor

Pull request is not mergeable.

@kjcjohnson kjcjohnson deleted the iss_1667 branch August 3, 2019 21:28
carlossg added a commit to jenkinsci/kubernetes-plugin that referenced this pull request Aug 24, 2019
To get the fix in fabric8io/kubernetes-client#1669

Origin header is set with port -1 when no port is present in the Kubernetes API url
carlossg added a commit to jenkinsci/kubernetes-plugin that referenced this pull request Aug 24, 2019
To get the fix in fabric8io/kubernetes-client#1669

Origin header is set with port -1 when no port is present in the Kubernetes API url

Causing an error on exec

```
java.net.ProtocolException: Expected HTTP 101 response but was '403 Forbidden'
```
daxmc99 added a commit to daxmc99/pipeline-jenkins-server that referenced this pull request Aug 26, 2019
Update plugins to pickup fix for origin headers found here fabric8io/kubernetes-client#1669
daxmc99 added a commit to daxmc99/pipeline-jenkins-server that referenced this pull request Aug 29, 2019
cjellick pushed a commit to rancher/pipeline-jenkins-server that referenced this pull request Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WatchConnectionManager's websocket Origin header uses port of -1 when no port specified
7 participants