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

Websocket handshake is failing with reverse proxy & HTTP Basic authentication #1167

Open
alexmaret opened this issue Nov 12, 2023 · 4 comments
Labels

Comments

@alexmaret
Copy link

Describe the bug
I'm running Commafeed behind an Apache reverse proxy, using HTTP Basic authentication, with the following configuration:

<VirtualHost *:443>
        ServerName news.domain.com

        SSLEngine on

        ProxyRequests Off
        ProxyPass        /ws ws://localhost:8082/ws
        ProxyPass        /   http://localhost:8082/
        ProxyPassReverse /   http://localhost:8082/

        <Proxy *>
            AuthType Basic
            AuthName domain.com
            AuthBasicProvider       ***redacted***
            AuthLDAPURL             ***redacted***

            Order deny,allow
            Allow from all
        </Proxy>
</VirtualHost>

Everything works fine, except for the websocket handshake which is repeated over and over again every second.

Browser Request:

GET /ws HTTP/1.1
Host: news.domain.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: */*
Accept-Language: en,en-US;q=0.8,de;q=0.5,de-DE;q=0.3
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https://news.domain.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: LeHQ0qtLUVU1imt1+Wa/Tg==
DNT: 1
Authorization: Basic ***redacted***
Connection: keep-alive, Upgrade
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Server Response:

HTTP/1.1 101 Switching Protocols
Date: Sun, 12 Nov 2023 10:06:59 GMT
Sec-WebSocket-Extensions: permessage-deflate
Connection: Upgrade
Sec-WebSocket-Accept: 0A3w/seHWzzgQd+7MjrMNwc+484=
Upgrade: WebSocket

Comparing the requests to the ones on commafeed.com, it seems the only notable difference is the Basic authentication and the missing cookie. Looks like commafeed does not set a cookie when using Basic authentication. Could this be the problem somehow?

To Reproduce
Steps to reproduce the behavior:

  1. Configure Apache reverse proxy as described above.
  2. Open Commafeed and monitor the network requests.
  3. The websocket connection negotiation will fail.
  4. Commafeed will try to restablish the connection every second.

Expected behavior
The websocket connection negotiation should succeed.

Environment (please complete the following information):

  • CommaFeed version (or "commafeed.com"): 3.10.0
  • Browser: Firefox, Brave
  • Device: Desktop
@Athou
Copy link
Owner

Athou commented Nov 21, 2023

CommaFeed is not doing anything fancy with the websocket connection (https://github.com/Athou/commafeed/blob/master/commafeed-client/src/hooks/useWebSocket.ts), Since you're saying the app works fine except the websocket connection,
it seems the browser decides to send the cookie for regular REST requests and the Basic Authorization header for websocket requests but I don't know why :/

@dstutz
Copy link

dstutz commented Jan 1, 2024

I don't know if it's related to this but I'm trying to get the new WS connections working through apache proxy as well. I noticed that the ws connection doesn't seem to be honoring the "applicationContextPath" setting from the config. The ws connection is requesting wss://www.domain.com/ws whereas the periodic tree refresh is hitting https://www.domain.com/<applicationContextPath>/rest/category/get. I think this is causing the re-write rules to not match since it's being served by the main vhost.

@Athou
Copy link
Owner

Athou commented Jan 1, 2024

I don't know if it's related to this but I'm trying to get the new WS connections working through apache proxy as well. I noticed that the ws connection doesn't seem to be honoring the "applicationContextPath" setting from the config. The ws connection is requesting wss://www.domain.com/ws whereas the periodic tree refresh is hitting https://www.domain.com/<applicationContextPath>/rest/category/get. I think this is causing the re-write rules to not match since it's being served by the main vhost.

You're right, the path was missing from the websocket URL, d9a9a01 should fix this, thanks!

I'm not sure this is the problem encountered by @alexmaret since the hostname in the example is news.domain.com with no path.

@Athou Athou added the bug label Jan 20, 2024
@rs-loves-bugs
Copy link

Can reproduce this issue with Caddy too, here's a sample config

commafeed.example.com {
  basicauth  {
        # Username "Bob", password "hiccup"
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy 127.0.0.1:8082
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants