commafeed
commafeed copied to clipboard
Websocket handshake is failing with reverse proxy & HTTP Basic authentication
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:
- Configure Apache reverse proxy as described above.
- Open Commafeed and monitor the network requests.
- The websocket connection negotiation will fail.
- 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
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 :/
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.
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 hittinghttps://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, d9a9a01a60abfccc922b44aa00312a5328eb8ad9 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.