Websocket handshake is failing with reverse proxy & HTTP Basic authentication

[alexmaret]

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]

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 but the Basic Authorization header for websocket requests but I don't know why :/

[dstutz]

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]

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.