Only m.login.password is implemented (backend/matrix/mod.rs's login path). A homeserver configured for SSO - which includes most corporate and many public ones, and is where the spec is heading with OIDC - cannot be signed into at all.
Done looks like: the login flow list is read, SSO opens a browser and completes through the redirect, and the token is stored like any other.
Only `m.login.password` is implemented (`backend/matrix/mod.rs`'s login path). A homeserver configured for SSO - which includes most corporate and many public ones, and is where the spec is heading with OIDC - cannot be signed into at all.
**Done looks like:** the login flow list is read, SSO opens a browser and completes through the redirect, and the token is stored like any other.
The login flows are read first, so a server offering only SSO is not shown a password form. SSO listens on loopback for the redirect, answers the browser with a page saying it can be closed, and exchanges the one-time token for a real one. The URL opens in the real browser, where a password manager and second factor already work. Read live from three homeservers — password only, password with SSO, and one that would not resolve — and the loopback handler is tested end to end.
An SSO account has no stored password, so anything password-gated will need the homeserver's own interactive auth.
Finished — https://git.salastil.com/Salastil/nobilis/commit/9882812 and https://git.salastil.com/Salastil/moho/commit/1a31ee4
The login flows are read first, so a server offering only SSO is not shown a password form. SSO listens on loopback for the redirect, answers the browser with a page saying it can be closed, and exchanges the one-time token for a real one. The URL opens in the real browser, where a password manager and second factor already work. Read live from three homeservers — password only, password with SSO, and one that would not resolve — and the loopback handler is tested end to end.
An SSO account has no stored password, so anything password-gated will need the homeserver's own interactive auth.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Only
m.login.passwordis implemented (backend/matrix/mod.rs's login path). A homeserver configured for SSO - which includes most corporate and many public ones, and is where the spec is heading with OIDC - cannot be signed into at all.Done looks like: the login flow list is read, SSO opens a browser and completes through the redirect, and the token is stored like any other.
Finished — https://git.salastil.com/Salastil/nobilis/commit/9882812 and https://git.salastil.com/Salastil/moho/commit/1a31ee4
The login flows are read first, so a server offering only SSO is not shown a password form. SSO listens on loopback for the redirect, answers the browser with a page saying it can be closed, and exchanges the one-time token for a real one. The URL opens in the real browser, where a password manager and second factor already work. Read live from three homeservers — password only, password with SSO, and one that would not resolve — and the loopback handler is tested end to end.
An SSO account has no stored password, so anything password-gated will need the homeserver's own interactive auth.