MSC3105: Previewing UIA flows #3105
Conversation
turt2live
added
client-server
turt2live
added
the
needs-implementation
| We could also completely replace UIA with some other system that either has built-in previewing | ||
| of similar constructs, or no need to perform auth in this way. This is not considered feasible by | ||
| this proposal in the timespan it intends to land within. | ||
|
|
There was a problem hiding this comment.
A third option would be to just spec what synapse currently does for /register. If no auth dict is present, it always returns 401 for a response. If no auth is needed, submitting a dummy stage is required, so this does not cause any conflicts. Of course clients can only rely on that behaviour on endpoints, that are marked as requiring UIA. I was actually about to submit a spec PR, because I thought this was just the spec being unclear. I would prefer that approach, because it fits what servers and clients already do, but it of course is not stateless (although clients can just throw away the session and we could possibly move the session creation to the first submitted auth dict) and could lead to accidental account deactivation or such, if servers implement UIA wrong.
| Servers are not required to predict the outcome of an `OPTIONS` request which also specifies a | ||
| `session` field - UIA does not lend itself to being able to determine if the flows would change and | ||
| thus is not expected to produce a sensible result. These secondary `OPTIONS` requests would most | ||
| likely be automatic preflight checks done by web browsers anyhow. |
There was a problem hiding this comment.
this is meaning to say that including a session should result in a 200 so the client doesn't fail preflight.
A bit difficult to determine how we'd figure out preflight for an unstarted session though...
|
|
||
| ## Proposal | ||
|
|
||
| When a UIA-supported endpoint is approached with an `OPTIONS` request the server would respond with |
There was a problem hiding this comment.
OPTIONS doesn't seem right. HEAD is probably the better method to use here.
There was a problem hiding this comment.
HEAD isn't right either, GET would be better
Rendered