Device removal doesn't work

[waclaw66]

Steps to reproduce

1. Select a session for removal
2. Click "Sign out 1 selected device"
3. A dialog is shown
   
4. Start authentication link https://my_homeserver/_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=TpDJpMZAnnTXJHRGDQuQPlvs returns {"errcode":"M_UNKNOWN","error":"Unknown auth stage type"}
5. Console contains Error getting device cross-signing info TypeError: can't access property "algorithms", e is null

Worth mentioning that I have set up https://github.com/devture/matrix-synapse-shared-secret-auth module.

Outcome

What did you expect?

Succesful removal

What happened instead?

Device cannot be removed

Operating system

Windows 10

Browser information

Firefox 96b5

URL for webapp

own

Application version

Element version: 1.9.8 Olm version: 3.2.8

Homeserver

own Synapse 1.49.0

Will you send logs?

No

[t3chguy]

This'll be a bug with your HS or the auth module not supporting fallback auth properly.

Most clients will have no idea how to perform com.devture.shared_secret_auth in UIA but your server is asking for it hence must also support it in the /fallback/ flow

[spantaleev]

Isn't it a bug in Element, because it's picking the first auth flow it sees, and not the one it actually supports: #19605

[t3chguy]

Start authentication link https://my_homeserver/_matrix/client/r0/auth/com.devture.shared_secret_auth/fallback/web?session=TpDJpMZAnnTXJHRGDQuQPlvs returns {"errcode":"M_UNKNOWN","error":"Unknown auth stage type"}

Is definitely a bug on the HS. But yes Element could/should prefer a different flow, not that the spec mandates that.

Closing in favour of #19605 but I do suggest you report it to the relevant backend project too.

[spantaleev]

Well.. Isn't the point of custom auth providers that they all get registered with the homeserver and that they are reported as valid for use.

When the homeserver tells you a bunch of auth flows are supported, why is it that Element picks the first one (that it doesn't understand) and goes to /auth/com.devture.shared_secret_auth/fallback/web? Especially when the current session had been started using a different auth flow. I suppose clients cannot know which auth flow was used for starting the session that they operate with, but even if they could.. it sounds reasonable that they never pick flows they don't understand.

I don't see how this is a homeserver bug. The homeserver is merely listing all auth flows that it supports. It doesn't need to care who the caller is and what their capabilities are. It's on the caller to do the sensible thing with the data that it's been given. It's the same for logging in, by the way. The homeserver reports a few valid ways to log in and clients are supposed to pick the one that they support. If Element saw com.devture.shared_secret_auth as the first one in the list and insisted on logging in like that (through fallbacks and whatnot), instead of picking a flow it supports, it'd be crazy.

[t3chguy]

I don't see how this is a homeserver bug.

The homeserver bug is that the /fallback/ isn't working.
Element may well not support any of the given UIAs and the fallback should always be wired up for all flows.

As I said above;

But yes Element could/should prefer a different flow, not that the spec mandates that.

That's what your issue, #19605 is about.

The homeserver reports a few valid ways to log in and clients are supposed to pick the one that they support.

The spec doesn't state this. See spec:

The client is free to choose which flow it follows, however the flow’s stages must be completed in order.

Right now Element's implementation is poor, but still valid as per the spec.

[t3chguy]

https://spec.matrix.org/v1.1/client-server-api/#fallback

This MUST return an HTML page which can perform this authentication stage. This page must use the following JavaScript when the authentication has been completed:

The backend is out of spec, in other words, is bugged.