Regressed at some point.
I don't see much reason not to link the bindable directly with config.
It seems to work as you'd expect. Tested with logout (resets to
"Online") and connection failure (persists).
Closes https://github.com/ppy/osu/issues/29173.
This is the first half of a change that *may* fix
https://github.com/ppy/osu/issues/26338 (it definitely fixes *one case*
where the issue happens, but I'm not sure if it will cover all of them).
As described in the issue thread, using the `jti` claim from the JWT
used for authorisation seemed like a decent idea. However, upon closer
inspection the scheme falls over badly in a specific scenario where:
1. A client instance connects to spectator server using JWT A.
2. At some point, JWT A expires, and is silently rotated by the game in
exchange for JWT B.
The spectator server knows nothing of this, and continues to only
track JWT A, including the old `jti` claim in said JWT.
3. At some later point, the client's connection to one of the spectator
server hubs drops out. A reconnection is automatically attempted,
*but* it is attempted using JWT B.
The spectator server was not aware of JWT B until now, and said JWT
has a different `jti` claim than the old one, so to the spectator
server, it looks like a completely different client connecting, which
boots the user out of their account.
This PR adds a per-session GUID which is sent in a HTTP header on every
connection attempt to spectator server. This GUID will be used instead
of the `jti` claim in JWTs as a persistent identifier of a single user's
single lazer session, which bypasses the failure scenario described
above.
I don't think any stronger primitive than this is required. As far as I
can tell this is as strong a protection as the JWT was (which is to say,
not *very* strong), and doing this removes a lot of weird complexity
that would be otherwise incurred by attempting to have client ferry all
of its newly issued JWTs to the server so that it can be aware of them.
(Or local date, in the case of non-deployed builds).
Came up when I was looking at https://github.com/ppy/osu-web/pull/11240
and found that we were still hardcoding this.
Thankfully, this *should not* cause issues, since there don't seem to be
any (documented or undocumented) API response version checks for
versions newer than 20220705 in osu-web master.
For clarity and possible debugging needs, the API response version is
also logged.
This is a prerequisite for https://github.com/ppy/osu/pull/25480.
The `WebSocketNotificationsClient` was tightly coupled to chat specifics
making it difficult to use in the second factor verification flow.
This commit's goal is to separate the websocket connection and message
handling concerns from specific chat logic concerns.
Them being together always bothered me and led to the abject failure
that is `APIUser` and its sprawl. Now that I'm about to add a flag that
is unique to `/me` for verification purposes, I'm not repeating the
errors of the past by adding yet another flag to `APIUser` that is never
present outside of a single usage context.
This is already handled amicably by the `Failing` -> `Connecting` flow.
Having this set in `handleRequest` throws things off, potentially
leading to the `Online` state change before the user has been populated.
This isn't really required as such, but feels more correct. There was no
reason for it to wait for the friend population to complete before
deeming things to be "online".
This allows for various components (like gameplay) to obtain a correct
username even if the API is not yet in a connected state. The most
common case is during startup, where a connection may not have been
established yet, but the user's username was restored from their config
file.
By making the change, local scores will now have the correct username
(although avatar etc. will be missing, which I think it fine) even if
the API is not yet connected. Previously, they would show up as "Guest".
All usages of this are made with the intention of showing data when an
api is going to eventually become available. In the case of a login
failure, components are also able to display a correct state.
With this change, it makes online components display in a more correct
state during startup or initial logging in phase.
This handles the case where on initial API connection, the server
responds with an `Unauthorized` response. It doesn't perform this same
checking/handling on every API request, which is probably what we want
eventually.
Opting to not address the full issue because I know this is going to be
a long one (see
05c50c0f6c/osu.Game/Online/API/APIAccess.cs (L233)).
A null there indicates a deserialisation error and therefore due to the
catch block immediately succeeding the changed line everything will
continue to work as intended.
