Stuck on animation screen when login with SSO

[wasiumks]

Unable to login using login with SSO.

Hang on animation logo screen.

[q3k]

I managed to troubleshoot this and implement a hacky fix: q3k@4083d60 . At least, this fixes the stuckness I'm observing with our HS and SSO/CAS flow.

It seems that as part of #2715 the MXKAuthenticationViewController was subclassed into an Element AuthenticationVC, replicating some of its original code, but changing it slightly. In this process, calls to MXCredentials initWithLoginResponse were changed to drop the andDefaultCredentials parameter. It used to be populated by the MXKAuthenticationVC's MXRestClient->credentials.

What seems to be happening is that the SSO flow JS calls window.matrixLogin.onLogin with an empty well_known (which I'm not sure why it happens on SSO-enabled servers, but is legal per the spec, at least per the Matrix Client/Server Spec, 5.5.2, Response Format). This cascades into causing authFallBackViewController didLoginWithLoginResponse to return broken MXCredentials.

These MXCredentials are broken by having homeServer be nil. This happens because of nil andDefaultCredentials in [[MXCredentials alloc] initWithLoginResponse:loginResponse andDefaultCredentials:nil]. The loginResponse passed to didLoginWithLoginResponse has a nil .wellKnown.homeServer.baseUrl (becuase the onLogin event did not have a well_known set. initWithLoginResponse then attempts to fix that by grabbing the homeserver from defaultCredentials, but those are also nil. As such, the returned MXCredentials have a nil homeServer.

The previous implementation of this, in MatrixKit's AuthenticationVC, would call initWithLoginResponse: .... andDefaultCredentials: self->restClient->credentials. This makes homeservers that return no well_known work, by always fixing up the generated credentials with whatever homeserver data was used to reach it in the first place. My fix replicates this, albeit in a very hacky way.

I'm sure a Matrix/Element developer, or even actual Objective-C developer can manage to write a proper fix and file a PR.

[q3k]

I've looked into this a bit further, and it seems like the issues is triggered not by SSO, but SSO and a specific Synapse configuration: public_baseurl was not set in Synapse's homeserver.yaml. This made it never return well_known in the login endpoint POST response.. However, this is not required to be set, and again, neither is the returned well_known field in the endpoint (“Optional client configuration provided by the server.”, per the Matrix Client-Server API Spec, r0.6.1, section 5.5.2).

It seems like this confirms the real culprit is the regression in #2715.

[q3k]

Note: I only hit this regression as a daily iOS Element user when I re-authenticated with the app, which I did after a new user said they had issues logged in. This might affect a lot of new users, but will be unreported by users who are already authenticated!