Closes https://github.com/ppy/osu/issues/28938.
This is related to reloading the composer on timing point changes in
scrolling rulesets. The lack of unsubscription from this would cause
blueprints to be created for disposed composers via the
`hitObjectAdded()` flow.
The following line looks as if a sync load should be forced on a newly
created placement blueprint:
da4d37c4ad/osu.Game/Screens/Edit/Compose/Components/ComposeBlueprintContainer.cs (L364)
however, it is not the case if the parent
(`placementBlueprintContainer`) is disposed, which it would be in this
case. Therefore, the blueprint stays `NotLoaded` rather than `Ready`,
therefore it never receives its DI dependencies, therefore it dies on
an `EditorBeatmap` nullref.
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.
Bookmarks don't show on real beatmaps, but they do show in test scenes
(namely `TestSceneEditorSummaryTimeline`).
Also does some more changes to adjust the markers to the latest updates
to other markers.
