mirror of
https://github.com/jcreek/CosmicClash.git
synced 2026-09-10 16:04:04 +00:00
Josh Creek
d588898f5d
The just-landed signed workload token embedded (allocation_id, match_id, server_id) as claims. That doesn't actually work for its intended delivery channel: the token is meant to be requested as a GameServerAllocation annotation in the SAME request that asks Agones to pick a server, so at mint time the allocator knows allocation_id (it generates it) but not yet which server_id Agones will return -- server_id only exists in Agones's response, after the annotation request has already been sent. Embedding it was simply not possible for the real caller this was built for; only the (allocator -> signed_token) unit tests and hand-constructed integration tests happened to supply it directly, masking the gap. Fixes it by having the token bind only allocation_id (the one identifier actually known at mint time) plus expiry. match_id/server_id are resolved at verify time from the durable allocations table via the new store.AllocationBindingByAllocationID, keyed by allocation_id -- which the allocator already records immediately after Agones responds. This is strictly stronger, not just a workaround: a caller can no longer claim any match/server pairing at all, even one that happens to be internally consistent -- the binding returned is entirely durable-record-derived. Verified: server/workload's unit tests updated for the new two-field claim shape; server/api's Postgres integration suite gains TestWorkloadVerifierFromSignedTokenNeverTrustsCallerSuppliedBinding (two distinct real allocations each resolve to their own, and only their own, match/server pairing) replacing the now-inapplicable mismatched-triple test. Full `go build ./... && go vet ./... && gofmt -l . && go test ./... -race` and `go test -tags integration ./... -race` both clean; the api integration suite re-run 3x clean against a live postgres:17-alpine container.