From 383e02835e5c9e60d0f574e69cf7cd6fa2cae262 Mon Sep 17 00:00:00 2001 From: David Baker Date: Tue, 14 May 2019 18:07:58 +0100 Subject: [PATCH] Words on using m.login.dummy for disambiguation Add some text on how m.login.dummy can be used to distinguish a flow that would otherwise be a subset of other flows. --- specification/client_server_api.rst | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index f9f815f7f..b2ff3dbd4 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -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 + 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: