jwed
33e465898c
Recorded because these outlived the session that produced them and every one is about code already committed. Six findings, most severe first. The reconciler as written would revoke every guest authorization on the whole UniFi site, not just the ones this portal created — front-desk vouchers, contractors, anything an admin authorized by hand — and re-authorize anything an admin deliberately revoked. That is why "not scheduled" is currently load-bearing rather than cautious. The pre-DHCP retry cannot succeed because all three attempts read one cached client snapshot, and the first failure warms that cache with a snapshot lacking the device, so "try again" stays refused for the TTL while holding a worker 1.5s per attempt. Every portal visit blanks the device fingerprint, because the controller writes three request parameters UniFi never sends. Session windows slide on every visit, so a bookmarked callback never ages out. And with no unique index on (user_id, mac_address) and no locking, concurrent callbacks can produce either two authorizations against a one-device limit or two rows for one phone that permanently consume two slots. Four tests pass for the wrong reason, including the headline quota-leak regression test: it asserts a component name that four different branches render, so it stays green with no role and no mapping at all. TWO CORRECTIONS from production evidence the operator supplied. The earlier claim that the request IP is forgeable was demonstrated by sending a header directly to nginx on :80. Clients cannot do that — the Wi-Fi VLAN is firewalled to Traefik only — so that demonstration does not show a live exploit and must not be cited as one. What survives is narrower: the app believes any X-Forwarded-For that reaches it, and whether a client can deliver a forged one depends on one forwardedHeaders setting on a Traefik host that is not reachable from here. And spec section E had its release-gate risk backwards. It feared TrustProxies would be too strict and lock everybody out. Production shows the opposite: the Logged-in Users list reports real per-client addresses, 10.22.5.x for on-site staff and a public address for an off-site phone. The IP-to-MAC approach is viable, with evidence, and that item is not a blocker. Also added: device type should come from the User-Agent, not from UniFi. The platform already parses "Safari · iPhone" and "Chrome · macOS" in ActiveSessionController::device(), and its OS table already separates iPhone, iPad and Android from the desktop platforms. That is available at authorization time, which UniFi's traffic-inferred dev_cat is not, and it is known to be populated, which dev_cat in this environment never was.