1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
|
VOIDERATION: CONSOLIDATED PRE-IMPLEMENTATION AUDIT
Date: 2026-10-30
Baseline: V22 + Stage 0; evidence reused from V15-V21 and local source.
Scope: Read-only. No dashboard, production API, deployment, code or revision changes.
EXECUTIVE STATUS
Overall: NOT READY for security implementation or production. READY only for
owner decisions and authorized read-only dashboard inventory. Most key risks
are confirmed in local code, but production deployment/settings are not verified.
The systems fit together only conditionally: the Photon custom-auth adapter,
PlayFab/Meta verification contracts, owner authorization and D1 persistence are
not implemented or proven. V22 is a target design, not a deployed control plane.
Status meanings: CONFIRMED = seen in local source/reports; CONDITIONAL = design
works if stated prerequisites pass; UNVERIFIED = dashboard, provider, or runtime
fact not observed; READY = safe to proceed with specified research/staging step,
not production release.
SYSTEM STATUS / GAPS
1. Identity, PlayFab roles, economy and CloudScript
- CONFIRMED: `Oculus_Login` uses Meta user ID as PlayFab Custom ID without Meta
server proof; obtains a PlayFab Photon token separately. UserData `Moderator`
is read by client and missing value is client-written FALSE. Client code has
direct `AddUserVirtualCurrency` callers. V08 is explicitly a draft and includes
weak caller/price assumptions; deployed revision is unknown. Client PlayFab
`PurchaseItem` and custom V08 `OnPurchaseItem` are distinct paths.
- CONDITIONAL: Server-owned roles, rewards and catalog purchases are feasible
only after every existing reward/purchase caller and product is migrated and
idempotency/restore are tested. Disabling old client paths early breaks features.
- UNVERIFIED: PlayFab API policies, live CloudScript/Azure functions and event
rules, moderator data source, catalog/store/currency setup, live purchase
validation, and PlayFab account history. No dashboard read.
- Gate: inspect policies/revisions/data permissions read-only; stage role and
economy migration before changing client permissions. Do not promote users
from client-writable Moderator values.
2. Photon auth, RPCs, reconnects
- CONFIRMED: Unity uses PlayFabId as Photon `username` and PlayFab-issued Photon
token as `token`. That token is NOT a PlayFab SessionTicket. The manager has a
20-second path that clears AuthValues and connects unauthenticated. Several
Tag/Infection RPCs lack sender checks; PUN owner/MasterClient does not make
gameplay authoritative. A normal Worker request cannot reliably kick a live
PUN Cloud actor.
- CONDITIONAL: Every-reconnect restriction check requires a supported Worker
custom-auth adapter that validates the Photon token using the documented
Photon/PlayFab contract, derives identity from validated response, and checks
D1. PlayFab `/Server/AuthenticateSessionTicket` validates a SessionTicket, not
the Photon token. Exact adapter wire format/provider support is not proven;
do not implement a guessed proxy. If unsupported, defer D1 login restrictions.
- UNVERIFIED: Photon Custom Server URL/provider, anonymous admission/failure
behavior, Realtime and Voice app association, reconnect/room-rejoin behavior,
targeted disconnect capability. No dashboard read.
- Gate: staging app must demonstrate auth failure never downgrades to anonymous,
normal reconnect/Voice/server-switch work, restricted new auth is rejected,
and existing session limitation is documented. RPC checks can reduce spoofing
but cannot prove an owner’s pose/hit/collision claim.
3. Meta User Verification, App Attestation and IAP
- CONFIRMED: No Meta proof validation or App Attestation implementation found.
Existing client IAP handlers grant rewards from callbacks; `OWNED_IAP` is
client-writable; reviewed paths have restore/transaction gaps. Actual product
fulfillment/replay behavior needs staging confirmation.
- CONDITIONAL: User Verification needs app permission/eligibility, supported SDK,
server-side nonce verification and account-link plan. App Attestation is an
optional integrity signal, not identity or proof of cheating. IAP requires
server entitlement verification, SKU mapping, idempotent durable fulfillment,
restore, and consume-after-success for consumables.
- UNVERIFIED: Meta DUC permissions/eligibility, SDK/API compatibility, signing,
product setup and current SKU/entitlement mapping. No dashboard read.
- Gate: preserve existing PlayFab identities, purchases and entitlements; stage
migration before enabling mandatory checks or disabling current fulfillment.
4. Cloudflare Worker, D1, heartbeat/replay and capacity
- CONFIRMED: local Worker has existing `/redeem`, `/motd`, Photon webhook,
Discord interactions, export/setup/health and `/updateplayers` no-op. `/redeem`
validates SessionTicket only for linking. No D1 binding, incident/restriction
routes, general session auth or heartbeat was found. Existing logging helper
swallows Discord errors; query-string secrets exist in some routes.
- CONDITIONAL: D1 incident, restriction, audit, outbox and heartbeat fit if
atomic/idempotent updates, route compatibility, session expiry, schema limits
and retry behavior are implemented. Heartbeat is liveness, not anti-cheat.
Missed beats/backend outage must not punish players. Existing routes/consumers
must be preserved; migrate URL secrets separately.
- UNVERIFIED: Deployed Worker version/routes/bindings/secrets (names only), D1
existence, plan and aggregate usage. Never request or record secret values.
- 100 CCU: five-minute heartbeat alone is ~28,800 Worker requests and ~28,800
D1 updates/day, before auth, incidents, reads and other Worker traffic. Free
plan fit is CONDITIONAL on shared account quotas/actual row accounting. €0
recurring is plausible, not established. Need staging load at 20/50/100 CCU,
inspect Worker requests and D1 rows_read/rows_written and set alert thresholds.
5. Discord alerts and incident review
- CONFIRMED: `ADMIN_CHANNEL_ID` points to `admin-logs` in local config/notes;
this does not prove privacy. Existing Discord logging is not a durable incident
outbox. Prior channel audit can be stale.
- CONDITIONAL: Worker -> D1 persist -> outbox -> Discord can provide durable,
deduplicated alerts. A private channel/bot with least privilege and retries
must be tested. Do not put tokens, receipts, raw IPs, proof nonce or unnecessary
evidence in alerts.
- UNVERIFIED: current destination, effective overwrites, webhook/bot mechanism,
credential owner and successful delivery. No Discord API/dashboard read.
- Gate: verify effective private permissions and test staging delivery, dedupe,
bounded retries and Discord outage. Alert failure must not lose incident or
change player access.
6. Incident status, restriction and rejoin policy
- CONFIRMED: no incident or restriction implementation exists. V21/V22 proposal
separates incident review (`PendingReview`, `Approved`, `Rejected`) from player
access state and ban. PUN connection auth is admission-time; already connected
restricted players may remain until disconnect.
- CONDITIONAL: rejoin enforcement works only with verified identity on every
Photon auth, D1 check, anonymous bypass closed, and fail-closed/retryable
behavior. Cannot reliably kick existing sessions through ordinary Worker call.
- Recommended default: all detections persist incident + owner alert. Movement,
latency, tracking loss, hand reach, client Tag overlap and single replay-like
noise: log/alert only, rejoin allowed. Candidate temporary PendingReview hold
only after repeated, authenticated, server-verifiable protocol abuse; never on
backend errors or one timeout. Owner `Approve/Clear` releases; `Reject/Confirm`
keeps `ConfirmedRestricted` until explicit owner release or separate ban.
Permanent ban is a distinct audited decision, never automatic from weak signal.
- Gate: owner selects per-rule restriction setting, expiry, review SLA, appeal
and retention. D1 outage means retryable denial for new auth only if the
restriction gate is enabled; never anonymous fallback. Existing sessions are
not mass-kicked.
7. Local owner dashboard
- CONFIRMED: no dashboard, D1 owner API or review workflow exists. Existing
Worker Discord interactions have signature/owner checks, but this is not a
dashboard authorization system.
- CONDITIONAL: local-only requires loopback bind (`127.0.0.1`), owner auth,
CSRF-safe mutations, short sessions and Worker-side authorization on every
action; browser must not connect directly to D1 or contain backend secrets.
- UNVERIFIED: owner identity/recovery, host machine, secure credential storage,
privacy/retention and approval policy. No existing dashboard settings to inspect.
- Gate: choose owner auth and recovery method; audit successes and denials.
8. Movement, behavior and gameplay authority
- CONFIRMED: V20 and source show client-influenced movement and PUN gameplay;
there are no validated numeric thresholds. Identified values (arm length 1.5,
Tag touchRadius 0.15, boost speeds 6.5/15) are implementation parameters, not
universal cheat thresholds.
- CONDITIONAL: calibrated telemetry can flag anomalies, with confidence reduced
for lag, frame spikes, tracking loss, stale samples, boosts and transitions.
PUN RPC sender/ownership/state/rate/sequence checks can reject invalid messages,
not make malicious owner state authoritative. Authoritative simulation requires
separate server architecture/cost.
- Gate: baseline clean play per mode/scene/boost and test false positives before
any restriction policy; no numeric enforcement threshold is READY today.
9. Feature preservation / regression surface
- CONFIRMED: existing features include PlayFab identity/economy, Meta checkout,
Photon rooms and Voice, reconnect/server switching, Tag/Infection, PVP,
movement, welding/Sandbox, horror hub and LVL1-7, items/cosmetics, `/link`,
MOTD and CCU. Worker and Unity changes cross multiple callers.
- READY: define release matrix now; no feature is approved for removal. Run
two-account and late-join tests, master/owner migration, room switching, Voice,
purchase/recovery and backend outage tests. Include duplicate manager/session
and retry/idempotency checks.
- Gate: staging feature parity and rollback plan before production rollout.
REMAINING DASHBOARD QUESTIONS (READ-ONLY INVENTORY)
1. PlayFab: deployed CloudScript/Azure Functions and PlayStream rules; Client API
policies; UserData/InternalData permissions; currencies/catalog/stores and
purchase/receipt controls.
2. Photon: Realtime Custom Server/provider URL, anonymous-client setting, auth
failure policy, PlayFab association, app IDs; Voice app/auth and reconnect.
3. Meta: User ID DUC/verification eligibility, attestation availability and
current product/SKU eligibility.
4. Cloudflare: deployed Worker/version/routes, binding names, D1 binding/schema,
plan and aggregate requests/rows. Do not expose secret values.
5. Discord: private channel effective permissions, bot/webhook identity and
delivery path; never reveal webhook URL/token.
IMPLEMENTATION DEPENDENCIES AND ORDER
0. Owner approves staging scope and read-only inventory; record redacted
settings, live revisions, app association and product mappings. Resolve
policies before touching behavior.
1. Identity/auth proof: decide Meta proof scope and account preservation; prove
Photon -> Worker -> PlayFab custom-auth contract in a staging app, including
Voice/reconnect and anonymous rejection. If proxy cannot be proven, defer
D1-gated Photon restrictions rather than guess.
2. Economy/moderation: server-owned roles, secure report/moderator operations,
currency rewards, PlayFab purchases and Meta IAP. Migrate all callers and
restore paths; verify grants exactly once before disabling client routes.
3. Worker/D1 foundation: schema, owner API, audit, durable alert outbox, limits,
secrets and route-compatibility tests. Preserve `/redeem`, `/motd`, Photon
webhooks, Discord commands, `/export`, `/setup`, `/health`; plan old query
secret migration separately.
4. Incident/manual review: trusted identity/provenance, every detection persisted
and alerted, owner-only audited transitions, loopback dashboard, per-rule
policy. Movement heuristics default non-restricting.
5. Heartbeat/replay and rejoin: five-minute challenge/sequence/expiry; no per-beat
KV; D1 restriction lookup at every auth; remove anonymous fallback only after
staging proves all login/reconnect/Voice paths. No reliable existing-session
kick claim.
6. RPC hardening + movement calibration; then staged rollout with rollback,
alert/quota monitoring and owner runbook. A dedicated authoritative game server
is a separate architecture and cost decision.
OWNER DECISIONS / RECOMMENDED DEFAULTS
- Approve staging-only implementation after redacted settings inventory; approve
production separately. Recommended: no production changes in Stage 1.
- Meta User Verification: optional until eligibility and existing-account binding
work; then decide whether to require. App Attestation: optional signal only.
- Confirmed moderator/role source: server-only. Do not trust existing UserData.
- Preserve every product/entitlement and current game mode; migrate before cutoff.
- Incident defaults: every signal gets incident + alert; movement/latency/tracking
never auto-restrict; only repeated verified protocol abuse may request temporary
hold; no automatic permanent ban.
- Review semantics: Approve/Clear releases; Reject/Confirm leaves confirmed
restriction until explicit release or separate ban. Require owner reason and
audit. Choose hold expiry, review SLA, appeal and evidence-retention period.
- Auth outage: retryable denial for new sessions if restriction enforcement is
enabled; never anonymous. Heartbeat outage is telemetry unavailable, not guilt.
- Discord: dedicated private owner/staff channel, least-privilege bot, bounded
retries and deduplicated alerts.
- Dashboard: owner-only local loopback, CSRF-safe server actions, no public host.
- Costs: target €0 additional recurring, but approve a quota threshold/traffic
alert and accept that capacity or authoritative-server needs may change cost.
TEST / RELEASE GATES
- Auth: valid/invalid/expired credentials; exact Photon token vs SessionTicket
separation; proxy contract; no anonymous downgrade; room rejoin, fresh login,
Voice, server switch, restricted denial and owner release. Simulate Worker,
PlayFab and D1 timeouts.
- Permissions/economy: forged moderator/target IDs denied; client cannot grant
currency or set role; every legacy reward and purchase maps correctly; duplicate
callbacks/retries grant once; catalog prices, Meta entitlement, consume/restore
and existing balances/items preserved.
- Incidents: every test detection persisted once with provenance/time/rule; alert
sent privately; Discord outage retries without loss/duplicate; non-owner/forged
dashboard actions denied; approve/reject/release/ban separately audited.
- Replay: duplicate/stale heartbeat, challenge reuse, sequence rollback, expiry,
lost response and retry; no restriction from missed beat or service outage.
- Gameplay: RPC sender/ownership/legal state/rate tests; Tag/Infection,
movement/boosts, PVP, welding/Sandbox, horror LVL1-7, levels/transitions, late
join, owner/master migration, items, room/Voice and duplicate manager checks.
- False positives/privacy: lag, tracking loss, frame spikes, normal movement and
tag proximity do not restrict; alert/logs exclude credentials and unnecessary
sensitive data; verify retention/deletion.
- Capacity: 20/50/100 CCU heartbeat plus expected incident/auth traffic; measure
actual Worker request and D1 row/read limits with existing routes. Set rollback
thresholds and confirm feature parity before rollout.
READINESS CONCLUSION
READY: owner review of this checklist and read-only dashboard inventory.
CONDITIONAL: staging implementation after decisions and provider/auth prerequisites.
UNVERIFIED: all production dashboard settings, deployments, quotas, alert privacy,
Meta eligibility and Photon proxy support.
NOT READY: production changes, D1-enforced Photon admission, automatic movement
restrictions, or any claim that existing PUN sessions can be reliably kicked.
Evidence reused: V15-V21 reports, V22, Stage 0, local `Oculus_Login.cs`,
`PhotonVRManager.cs`, IAP/economy scripts, `discord-bot/worker.js`, and V08 draft.
No dashboard access or production calls were made.
END OF REPORT
|
Pastebin