[global.well_known] client should be considered MUST-populate post OAuth adoption #2116

New issue

Open

opened 2026-08-08 04:10:03 +00:00 by julian45 · 4 comments

julian45 commented

2026-08-08 04:10:03 +00:00

Member

This is at least a matter of some light edits to src/core/config/mod.rs comments and conduwuit-example.toml; that said, it might be "best" in the long run if c10y failed to start if this setting is unconfigured (to force deployers to put a value in there).

What it says on the tin. Regardless of homeserver delegation to another domain or use of a separate port, or whether you have a separate web server serving your .well-known/matrix/ basics, this now MUST be populated in at least the server settings—whether in the TOML file or via the `CONTINUWUITY_WELL_KNOWN__CLIENT` env var—or else it's impossible to sign in with new clients. Even *I* fell victim to this classic blunder when setting up my first new client post-26.6.0, and we've had at least one or two newcomer adopters miss this as well. This is at least a matter of some light edits to `src/core/config/mod.rs` comments and `conduwuit-example.toml`; that said, it might be "best" in the long run if c10y failed to start if this setting is unconfigured (to force deployers to put a value in there).

stratself commented

2026-08-08 04:57:54 +00:00

Member

The well known requirement is already documented here.

Could we have a graceful fallback where, without client .well-known, Continuwuity will use https://server_name:443 for OAuth? This would be consistent with generic/dockerized deployment pages

The well known requirement is already documented [here](https://continuwuity.org/guides/delegation#option-2-manually-serving-static-files-for-well-known). Could we have a graceful fallback where, without client `.well-known`, Continuwuity will use `https://server_name:443` for OAuth? This would be consistent with generic/dockerized deployment pages

julian45 commented

2026-08-08 05:08:02 +00:00

Author

Member

If I remember my post-upgrade issue with this correctly, the fallback you describe is already present, but that simply does not work in delegated situations.

nex commented

2026-08-08 11:28:45 +00:00

Owner

@stratself wrote in #2116 (comment):

Could we have a graceful fallback where, without client .well-known, Continuwuity will use https://server_name:443 for OAuth? This would be consistent with generic/dockerized deployment pages

I'd be for a fallback, but it would have to be :$CONTINUWUITY_PORT, not static :443

@stratself wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/2116#issuecomment-33905: > Could we have a graceful fallback where, without client `.well-known`, Continuwuity will use `https://server_name:443` for OAuth? This would be consistent with generic/dockerized deployment pages I'd be for a fallback, but it would have to be `:$CONTINUWUITY_PORT`, not static `:443`

stratself commented

2026-08-16 09:08:20 +00:00

Member

I disagree with :$CONTINUWUITY_PORT as none of our docs (and nobody in general) expose c10y without a reverse proxy. This would essentially make [matrix.well_known].client a soft requirement. :443 is already the default for Client-Server API as well

I disagree with `:$CONTINUWUITY_PORT` as none of our docs (and nobody in general) expose c10y without a reverse proxy. This would essentially make `[matrix.well_known].client` a soft requirement. `:443` is already the default for Client-Server API as well

stratself added the

Documentation

Matrix/Client

Matrix/Auth

labels

2026-08-16 12:53:21 +00:00