commit | 1db03c32b65a931f9f2a5271e9be10264a5dbe73 | [log] [tgz] |
---|---|---|
author | Serge Bazanski <q3k@hackerspace.pl> | Wed Aug 26 18:10:36 2020 +0000 |
committer | Serge Bazanski <q3k@hackerspace.pl> | Wed Aug 26 18:10:36 2020 +0000 |
tree | c7244a77b32920784046b54034198b1a1dde26e6 | |
parent | de6275101bcf9201061491831cb869f82270eeda [diff] |
matrix: fix iOS signup issues by specifying public_baseurl WHITE WHALE HOLY GRAIL Complex systems are complex. Let me tell you a story about that. Matrix clients perform their last stage of login by performing a POST to /_matrix/client/r0/login on the Matrix homeserver they log in to. How they reach the Homeserver is specified earlier - either by using discovery via SRV or .well-known, or by the client manually specifying the Matrix homeserver URL. Regardless of how they reach this endpoint in the first place, this POST endpoint, as per the Matrix Client-Server API Specification (r0.6.1), MAY return a `well_known` key, which MUST contain a `homeserver` address, pointing to the address of the homeserver which the client should talk to. If present, the client SHOULD use that instead of whatever it connected to so far. Issue the first: the iOS client requires `well_known` in that response, and doesn't work otherwise. https://github.com/vector-im/element-ios/issues/3448 Issue the second: Synapse will return `well_known` accordingly, but only if `public_baseurl` is set in its configuration. It is not required to be set. If not set, it will simply not return this key. Shrek the third: we never set `public_baseurl` in Synapse, and the first issue (iOS needing `well_known`) only became a regression in https://github.com/vector-im/element-ios/issues/2715 . As such, it was difficult to troubleshoot this issue, and we kept getting on some red herrings: is it the SSO? Is our server broken? Is the iOS implementation broken? But now we know - https://github.com/vector-im/element-ios/issues/2715 seems to be the true culprit. Change-Id: I913792e31e3c6813d4e51d4befdba720cad3f532
hscloud
is the main monorepo of the Warsaw Hackerspace infrastructure code.
Any time you see a //path/like/this
, it refers to the root of hscloud, ie. the path path/like/this
in this repository. Perforce and/or Bazel users should feel right at home.
For a pleaseant web viewing experience, see this documentation in hackdoc. This will allow you to read this markdown file (and others) in a pretty, linkable view.
See //doc/codelabs for tutorials on how to use hscloud.
If you want to browse the source of hscloud
in a web browser, use cs.hackerspace.pl.
If you want some other help, talk to q3k, informatic or your therapist.
Directories you should care about:
k0.hswaw.net
)Unless noted otherwise, code in hscloud is licensed under the BSD 0-clause license - see COPYING.