Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restores support for default_server_name which discovers URLs via .well-known #2669

Merged
merged 7 commits into from
Feb 21, 2019

Conversation

jryans
Copy link
Collaborator

@jryans jryans commented Feb 20, 2019

#2327 previously added support for a default_server_name config property which when set, will trigger a .well-known discovery to find the default HS and IS URLs.

Some of this got lost in the recent auth churn, so this restores that functionality, and also adds further tweaks from element-hq/element-web#8763 to the text around accounts.

image

image

In these screenshots, onett.local is my local machine where I set up a dummy .well-known pointed elsewhere. My local Riot is then set to use "default_server_name": "onett.local".

Each commit in this PR has additional context in the commit message, so you may want to review commit by commit.

Fixes element-hq/element-web#8763.

Modular now sets `disable_custom_urls`, so the server type selector is not shown
for Modular-hosted Riot.
`ServerTypeSelector` would call its `onChange` prop both at construction
(because it computed the default selected type and consumers might want to know)
as well as on actual user change. This ended up complicating consumer code, as
they want to differentiate between initial state and changes made by the user.

To simplify things, `ServerTypeSelector` now exports a function to compute the
server type from HS URL, which can be useful for setting its initially selected
type. The consumer now provides that type via a prop, and `onChange` is now only
called for actual user changes, simplifying the logic in `Registration` which
uses `ServerTypeSelector`.

In addition, some usages of `customHsUrl` vs. `defaultHsUrl` in `Registration`
are simplified to be `customHsUrl` only (since it already includes a fallback to
the default URL in `MatrixChat`).
If a default server name is set and the current HS URL is the default HS URL,
we'll display that name in the "your account" text on the registration form.

This can be a bit more user friendly, especially when the HS is delegated to
somewhere such as Modular, since you'll then see "example.com" instead of
"example.modular.im", which you have no direct relationship with as a user.

This is the key bit of element-hq/element-web#8763 for
registration.
If a default server name is set and the current HS URL is the default HS URL,
we'll display that name in the "sign in to" text on the login form.

This can be a bit more user friendly, especially when the HS is delegated to
somewhere such as Modular, since you'll then see "example.com" instead of
"example.modular.im", which you have no direct relationship with as a user.

This is the key bit of element-hq/element-web#8763 for
login.
If a default server name is set and the current HS URL is the default HS URL,
we'll display that name in the "your account" text on the forgot password form.

This can be a bit more user friendly, especially when the HS is delegated to
somewhere such as Modular, since you'll then see "example.com" instead of
"example.modular.im", which you have no direct relationship with as a user.

This is the key bit of element-hq/element-web#8763 for
forgot password.
Now that auth flows can show a server name like `example.com` which might
delegate the HS to some other server, it could be confusing to see text like
"Sign in to example.com", especially if `example.com` runs an identity service,
uses SSO, has its own account system, or other things like this.

To clarify that we mean Matrix accounts, all auth flows are updated to talk in
terms of "<verb> your Matrix account on <server>".

Fixes part of
element-hq/element-web#8763 (comment).
The forgot password link should prevent default to avoid changing the URL's hash
state.
@jryans jryans requested a review from a team February 20, 2019 17:54
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. It definitely serves as a reminder that our auth system is complicated and in desperate need of a major refactoring though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants