Consider UIA flow design on deactivation dialog #13646
Labels
T-Task
Tasks for the team like planning
X-Needs-Design
X-Needs-Investigation
X-Needs-Product
More input needed from the Product team
Z-t3chguy
Comments
turt2live
added
T-Task
turt2live
added a commit
to matrix-org/matrix-react-sdk
that referenced
this issue
May 12, 2020
Fixes element-hq/element-web#13645 Every time the checkbox value changes we acquire a new session now. This avoids us asking the server to change its direction partway through the request. This causes a bit of UI jerk as the dialog goes from auth -> loading -> auth, however it's better than the alternative of reworking the entire UIA structure to support the `authData` dict changing. Originally this commit consisted of a `disabled` flag on the `InteractiveAuth` component which carried through to the stage's component, however it turns out that stack doesn't respect changes to the `authData` prop, which means the session ID we eventually send down is wrong (`erase: false` instead of the one with `erase: true`). Therefore, we do some logic to ensure we remount `InteractiveAuth` completely. Further work in this area is described in element-hq/element-web#13646
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When doing UIA the intent of the request can't be changed per the spec, which means the user can't suddenly decide that they want to erase themselves without abandoning their current auth attempt. However, riot relies on a previous bug in Synapse where we could change the parameters in the middle of the flow.
We hit the server for the auth flows to see what form of password entry we need (SSO, actual password, etc) and show that alongside a checkbox to optionally erase their data. This erasure checkbox is the thing that can change the parameters of the request, which the spec doesn't like (and neither does Synapse, now).
The workaround is for us to start a new session once the user commits to deactivating their account (starting the auth flow), though this is hard to do with SSO and similar flows. For the workaround, we hope that people won't click a checkbox after they've started auth - something they couldn't do for password auth anyways. This workaround raises a problem with the server's behaviour though.
The server only has to honour the flow the client is using while the session ID is active (assigned during the initial request). This means that when we start a new session the user could get different flows to complete all of a sudden (rendering the password previously entered potentially useless). The server also has an opportunity to deny the existence of a session ID, which we historically have not handled.
One cheap workaround is to have the erase checkbox and the auth steps on different screens (like a 'next' button before you can enter a password). This feels a bit like a wizard though, which historically we've been against for smaller actions (longer actions like cross-signing setup appear to be good fits).
This might be a fun exercise in what to do about UIA more generally, as it's complicated and doesn't fit our current designs. We could figure out what design works best for us, write an MSC or two, and try and get that through or potentially just design a complicated system which matches the spec's behaviour.
The text was updated successfully, but these errors were encountered: