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.

Sign up for GitHub

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

Jump to bottom

Words on using m.login.dummy for disambiguation #1999

Merged
merged 2 commits into from May 15, 2019
Merged

Words on using m.login.dummy for disambiguation #1999

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
383e028
Words on using m.login.dummy for disambiguation
dbkr May 14, 2019
c38581f
Too many spaces
dbkr May 14, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 8 additions & 1 deletion specification/client_server_api.rst
View file
Open in desktop
Expand Up @@ -789,7 +789,14 @@ Dummy Auth
:Description:
Dummy authentication always succeeds and requires no extra parameters. Its
purpose is to allow servers to not require any form of User-Interactive
Authentication to perform a request.
Authentication to perform a request. It can also be used to differentiate
flows where otherwise one flow would be a subset of another flow. eg. if
dbkr marked this conversation as resolved.
Show resolved Hide resolved
a server offers flows ``m.login.recaptcha`` and ``m.login.recaptcha,
m.login.email.identity`` and the client completes the recaptcha stage first,
the auth would succeed with the former flow, even if the client was intending
to then complete the email auth stage. A server can instead send flows
``m.login.recaptcha, m.login.dummy`` and ``m.login.recaptcha,
m.login.email.identity`` to fix the ambiguity.

To use this authentication type, clients should submit an auth dict with just
the type and session, if provided:
Expand Down