Closed MiloradLalovic closed 1 year ago
I see the problem. However, your proposed fix would introduce a potential security issue when Galene is being run behind a firewall. I'll think it over.
Sorry, I accidentally sent a comment from my fork of Galene, it was more like note than the fix. Anyway, I ran Galene behind a proxy server which also acts as a TLS termination proxy and I found that the WebSocket connection couldn't be established because of CORS, so I did a little modification in web server implementation. By the way, the Galene is great software and very easy to configure. Thanks.
I'd be glad to add an option that disables origin checking, but I'd like to make sure it's really necessary.
The default behaviour is to check that the host indicated in the Origin
header is equal to the host indicated by the Host
header. Thus, you may run into problems if your reverse proxy rewrites the Host
header but doesn't rewrite the Origin
header.
Can you confirm that this is indeed the case? Could you please try configuring your proxy so that it does not rewrite the Host
header? (You'll need to use current master and use the proxyURL
configuration option in Galene.)
When I added " add_header Access-Control-Allow-Origin *" to the proxy settings in "/ws" section with the original code and "-insecure" option the error with the "wss" connection in the browser has gone.
Ok. I see. Should Galene be including this header on the WS endpoint? Or should that be an option in the group configuration file?
After careful consideration, I've come to the conclusion that this header should not be required. I suspect that you have not configured the public hostname correctly.
Closing for now. Please confirm whether the header is still needed if the hostname is configured correctly, and reopen if required.
Fixed wss checkOrigin error when Galene is behind Proxy HTTPS->HTTP