Open kaizushi opened 1 year ago
The room "URL" isn't ever accessed directly; rather Session just uses a fake URL to encode the base URL + room name + public key. All actual requests go via encrypted POST requests to /oxen/v4/lsrpc
. (We have a plan to adapt the room URL to coincide with the web viewer so that, for public groups, there will be something at that URL, but currently, Session doesn't expect to find the /r/
in the URL.)
Is there a way for Session to give more detailed output about why connecting to the room fails?
There should be info in the log file (~/.config/Session/logs/log.log or something like that). It can take some sifting through. though.
I have created a SOGS server. and it works in the browser and I can see the QR code and such. I am using SOGS standalone, but technically the site is behind a reverse proxy. That should not really matter, as the virtual host used remains the same. It is just that the actual SOGS server is hidden behind a Tor hidden service, and a proxy handles getting things from an ordinary URL using an nginx proxy.
Despite this, I cannot seem to connect to the group with Session which gives a pretty generic error that it 'couldn't join the community.' I decided to investigate with a very verbose curl run of the same URL I am using...
Note: I have redacted information using X characters.
I believe there may be an issue with my nginx configuration not passing the public key variable properly, since the front page with the room list and the room itself work, and the QR code is there and all that.
Here is the nginx configuration (also redacted)...
The proxy_pass heads to an SSH tunnel to the hidden server. I think something here is garbling the request and it's not getting through properly. In theory it should work because as I mentioned earlier the virtual host remains the same.