Add two factor authentication flow

[peppy]

Draft as this requires osu-web implementation.

Flows required:

• Endpoint to perform verification
• Endpoint to re-request verification code
• Response from a request (either error or otherwise) to let us know that verification hasn't been performed. ie. consider the case where the user does user/password login then quits the game before 2FA authenticating – to handle this, osu-web needs to let us know that we should show the flow again.

@nanaya is looking into the above requirements

• Closes Two factor authentication needs to be implemented #20590
• Depends on Decouple notifications websocket handling from chat operations #26724

---

CleanShot.2023-11-16.at.09.34.04.mp4

[bdach]

Aside from the test failures

[AAGaming00]

Is proper TOTP also going to be considered in the future? I feel like it could be more convenient for a lot of people and is more secure.

[peppy]

Is proper TOTP also going to be considered in the future? I feel like it could be more convenient for a lot of people and is more secure.

ppy/osu-web#5163 searching is not hard

[AAGaming00]

Oh I searched the wrong repo oops.

[bdach]

I've pushed some stuff here and the basic flows appear to work. I'm not sure I'm super happy with the code, though.

First of all, the current "notification client" is almost glued to chat in its construction. Like have a look at WebSocketNotificationClient on master. It's half websocket handling logic, half chat specific stuff (things like fetching chat updates in ConnectAsync() via... calling base). I've attempted to basically step over that in 62a0c23 by splitting out the part I care about (the osu! ws glue code) from the rest but not sure how to feel about adding another layer to that lasagna.

Secondly there's e3eb7a8: turns out that the previous flow of consumption of the notification websocket (a) was half-reliant on the user API state being online, (b) required to request the user's notifications to retrieve the address of the notification websocket endpoint:

osu/osu.Game/Online/Notifications/WebSocket/WebSocketNotificationsClientConnector.cs

Lines 30 to 35 in b272d34

	var req = new GetNotificationsRequest();
	req.Success += bundle => tcs.SetResult(bundle.Endpoint);
	req.Failure += ex => tcs.SetException(ex);
	api.Queue(req);
	string endpoint = await tcs.Task.ConfigureAwait(false);

I'm not sure that's going to work if the user's session isn't verified, and it also seems turbo weird to do this. So I just hardcoded the websocket address. I'll likely want to ask the web team as to whether this is anywhere near acceptable.

There's also the part where any failure to set up the websocket listener basically is met with "welp, there was an attempt, enter the code manually or go away". Not sure how much I should care about that.

Tests will probably fail. And there are no new tests exercising the new logic. I'll come back to that tomorrow.

[nanaya]

the main idea for /endpoint is to avoid hardcoding the url in web (web build/deployment constraints etc). Whether or not it should be hardcoded in client would be just deployment consideration (both for client and notification server).

There's no particular reason why it requires authentication apart of there's no exclusion for it from requiring one and that it's not usable without authentication anyway.

[bdach]

I think I'm okay with where this is at right now, but this is dependent on #26724 now.

[peppy]

Seems to work well. @bdach I've deployed the required changes to staging if you want to give it a final test, but I think this is good to go from my end.