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

Unhide secure cookies when behind TLS-originating HTTP-Proxy #833

Open
twiechert opened this Issue Mar 1, 2019 · 7 comments

Comments

Projects
None yet
2 participants
@twiechert
Copy link

twiechert commented Mar 1, 2019

We use the Java cometd client behind a TLS-orginating http proxy. Thus, the communication between cometd client and proxy is unencrypted through plain http.

This will cause the Java cookie store used in LongPollingTransport to not expose cookies flagged by the server as secure

This is very likely to be the actual cause for #644.
Since we observed exactly the same error messages, eventually caused by the missing cookie Information.

Are you aware of a way to "convince" the cookie store to also expose the secure cookies. Or otherwise, do you consider it a useful feature in cometd to allow a workaround of this security feature in Java?

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 1, 2019

I'm not sure I understand.
Are you saying that BayeuxClient.getCookie(String) returns null for a non-CometD cookie sent by the CometD server?

@twiechert

This comment has been minimized.

Copy link
Author

twiechert commented Mar 1, 2019

for (HttpCookie cookie : getCookieStore().get(uri))in LongPollingTransport returns only cookies that have not been flagged as secure in case you pass an URL that does not start with https. This is a secuity feature but very annoying if the application sits behind a TLS originating http proxy:

Cometd App --> HTTP --> Envoy --> HTTPS -> Salesforce
(Salesforce returns secure cookies such as BAYEUX_BROWSER)

These cookies are omitted in the subsequent requests, thus leading to auth errors.

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 1, 2019

Why is not "Envoy" stripping the secure flag?

@twiechert

This comment has been minimized.

Copy link
Author

twiechert commented Mar 1, 2019

Yes, it can be built like this, modifying the response headers received by salesforce.

However, this seemed to have caused trouble for other people as well:
#644
(you find other references to this 403 error on google as well without clearly identified root cause)

So basically I wanted to create awareness for this "problem" and potentially help others who face the same issue.

A very simple "fix", yet not ideal would be to build the lookup url in LongPollingTransportlike this

final URI uri = URI.create(url.replace("http://", "https://"));

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 1, 2019

@twiechert what about this: the retrieval of the cookies can be factored out to a method that you would be able to override and implement your logic.

Would that solve this issue?

@twiechert

This comment has been minimized.

Copy link
Author

twiechert commented Mar 1, 2019

Sounds amazing :)

@sbordet

This comment has been minimized.

Copy link
Member

sbordet commented Mar 1, 2019

@twiechert wanna give it a try and issue a PR? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.