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

Fix a websocket connection issue when running in the proxy mode #2089

Open
wants to merge 1 commit into
base: py3
Choose a base branch
from

Conversation

wandrien
Copy link
Contributor

Steps to reproduce:

  1. Run Zeronet with --ui_trans_proxy in a docker container or other isolated environment.
  2. Set 127.0.0.1:43110 as a HTTP Proxy in a browser.
  3. Navigate to http://talk.zeronetwork.bit/
  4. The site stops loading, since the websocket connection isn't functional.

The bug consists of 2 related issues:

  1. Connect to the proper address.

    When running in the proxy mode, Zeronet sends its env["SERVER_NAME"] and env["SERVER_PORT"] as the websocket destination address in the wrappper HTML code (variable server_url). That looks wrong for me, since the values of those variables have nothing to do with the actual address accessible by the browser. ZeroNet can run in a container, the connection also can be tunneled over SSH and so on. In all those cases, the internal SERVER_NAME makes no sense as the destination at all.

    The code for sending and handling server_url is deleted. The browser should connect to the websocket in the same way as it connects to the ZeroNet UI in general.

  2. Send the proper response for CONNECT requests.

    A browser tries to connect to the correct address, but it still fails. A browser, when connecting via a HTTP proxy to a webdocket, uses the HTTP tunneling protocol, and ZeroNet lacks support for it. To fix this, it's enoght to send the "200 OK" response on the CONNECT method request.

Steps to reproduce:

1. Run Zeronet with --ui_trans_proxy in a docker container or other isolated environment.
2. Set 127.0.0.1:43110 as a HTTP Proxy in a browser.
3. Navigate to http://talk.zeronetwork.bit/
4. The site stops loading, since the websocket connection isn't functional.

The bug consists of 2 related issues:

1. Connect to the proper address.

   When running in the proxy mode, Zeronet sends its env["SERVER_NAME"] and env["SERVER_PORT"] as the websocket destination address in the wrappper HTML code (variable `server_url`). That looks wrong for me, since the values of those variables have nothing to do with the actual address accessible by the browser. ZeroNet can run in a container, the connection also can be tunneled over SSH and so on. In all those cases, the internal SERVER_NAME makes no sense as the destination at all.

   The code for sending and handling `server_url` is deleted. The browser should connect to the websocket in the same way as it connects to the ZeroNet UI in general.

2. Send the proper response for CONNECT requests.

   A browser tries to connect to the correct address, but it still fails. A browser, when connecting via a HTTP proxy to a webdocket, uses the [HTTP tunneling protocol](https://en.wikipedia.org/wiki/HTTP_tunnel), and ZeroNet lacks support for it. To fix this, it's enoght to send the "200 OK" response on the CONNECT method request.
@wandrien
Copy link
Contributor Author

wandrien commented Jul 10, 2019

We still have some bugs here.

UiRequest doesn't allow what it should:

http://zero/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/ returns "Forbidden"

And allows what it shouldn't:

CONNECT accepts just any connection. So Firefox tryes to open SSL connections to *.firefox.com and sends encripted garbage there.

But this should be fixed in a different pull request, I guess, as it affects other parts of UiRequest.

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.

1 participant