fix(multiplayer): bind signed workload tokens to allocation_id only

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.
This commit is contained in:
Josh Creek
2026-09-01 14:54:38 +01:00
parent 939b7a9584
commit d588898f5d
5 changed files with 118 additions and 86 deletions
+8 -4
View File
@@ -90,12 +90,16 @@ func WorkloadVerifierFromSignedToken(secret []byte, db *sql.DB) WorkloadVerifier
return domain.WorkloadBinding{}, err
}
// WorkloadVerifier has no context parameter (see its type in
// service.go) so the durable cross-check below cannot inherit the
// service.go) so the durable lookup below cannot inherit the
// caller's request context; bound it locally instead of running
// unbounded against context.Background().
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
ok, err := store.AllocationBindingStillValid(ctx, db, claims.AllocationID, claims.MatchID, claims.ServerID)
// The token only names allocation_id (see signed_token.go for why);
// match_id/server_id come from the durable allocator record, never
// from the caller, so a token can never claim a pairing that wasn't
// actually, durably allocated.
matchID, serverID, ok, err := store.AllocationBindingByAllocationID(ctx, db, claims.AllocationID)
if err != nil {
return domain.WorkloadBinding{}, err
}
@@ -104,8 +108,8 @@ func WorkloadVerifierFromSignedToken(secret []byte, db *sql.DB) WorkloadVerifier
}
return domain.WorkloadBinding{
AllocationID: claims.AllocationID,
MatchID: claims.MatchID,
ServerID: claims.ServerID,
MatchID: matchID,
ServerID: serverID,
}, nil
}
}