Closed affenull2345 closed 9 months ago
The well_known
property of login info is particularly insidious. I had configured my server to serve a .well-known
(which should be unnecessary), and chooj appeared to let me successfully log-in but couldn't load chats and had me wait indefinitely, because chooj internally sets the homeserver url from the well_known
property of the first successful login. If that property is not returned, then chooj fails to login silently (well it prints a crypting exception to console)
It goes without saying that the homeserver url should be obtained differently. Ideally the flow should be:
example.com
https://example.com/.well-known/matrix/client
https://example.com
Regardless of the above, then:
well_known
property, then use it and override the previously set homeserver URL By the way, the "workaround" as a synapse server admin should be to have the following config:
serve_server_wellknown: true
public_baseurl: https://matrix.example.com
This ensures the server actually returns the well_known
property upon login
https://spec.matrix.org/latest/client-server-api/#well-known-uri states:
This means that chooj shouldn't rely on the fetch() for this file to be successful. Instead, it should fall back to the specified homeserver address as the base URL. I think this fall back should be done for all errors, not just 404.
The same goes for the
well_known
property of the login info: https://spec.matrix.org/latest/client-server-api/#post_matrixclientv3login states that it is optional: