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

MSC3105: Previewing UIA flows #3105

Open
wants to merge 2 commits into
base: old_master
Choose a base branch
from

Conversation

turt2live
Copy link
Member

@turt2live turt2live changed the title MSC: Previewing UIA flows MSC3105: Previewing UIA flows Apr 6, 2021
@turt2live turt2live added client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal proposal-in-review labels Apr 6, 2021
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Comment on lines +29 to +32
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.
Copy link
Member Author

Choose a reason for hiding this comment

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

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
Copy link

Choose a reason for hiding this comment

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

OPTIONS doesn't seem right. HEAD is probably the better method to use here.

Copy link

Choose a reason for hiding this comment

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

HEAD isn't right either, GET would be better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants