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.
At this point its primary usage is the daily challenge event feed, but
the leaderboard will be using this too shortly.
Because the playlists results screen that exists in `master` is
hard-coupled to showing the *local user's* best result on a given
playlist by way of hard-coupling itself to the relevant API request,
allowing show of *arbitrary* score by ID requires a whole bunch of
subclassery as things stand. Oh well.
Class naming is... best effort, due to the above.
Regressed in https://github.com/ppy/osu/pull/28399.
To reproduce, enter a playlist that has an item with a rate-changing mod
(rather than create it yourself).
This is happening because `APIRuleset` has `CreateInstance()`
unimplemented:
b4cefe0cc2/osu.Game/Online/API/Requests/Responses/APIBeatmap.cs (L159)
and only triggers when the playlist items in question originate from
web.
This is why it is bad to have interface implementations throw outside of
maybe mock implementations for tests. `CreateInstance()` is a scourge
elsewhere in general, we need way less of it in the codebase (because
while convenient, it's also problematic to implement in online contexts,
and also expensive because reflection).
(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.
