A public demo has nothing real to show for anything that needs an
external system: no GeoLite2 city database, no reachable backends, no
DNS provider credentials, no traffic. Those screens were empty or red.
Fabricate that state in one place. Each subsystem gains a provider slot
defaulting to nil, and internal/demo is the only package that fills
them, from a single call in boot. A production binary never calls
Install, so the slots stay nil and this code is unreachable rather than
merely un-taken — an `if demo` branch at each call site would fail
silently when it fails, which is exactly the mode to exclude here.
Fabrication happens at the INPUT to the real pipeline. The fake
GeoIPService feeds the real parser, indexer and searcher, so facets,
filters and time ranges stay honest code under test.
Every fake is a partial function. The geo provider answers only for the
RFC 5737/3849 documentation ranges that the synthetic access log itself
uses, and defers to the country database cosy already embeds for
everything else; the upstream and site probers answer only for the
targets the demo created. So even installed by mistake on a real node,
none of them could invent a claim about an operator's own traffic or
backends.
Values are pure functions of their input (FNV-1a over the key), not
draws from a shared PRNG: the log parser memoises per IP across a worker
pool, so a shared source would freeze whichever answer won the race.
Things that should look alive hash against a 5-minute bucket instead of
a timestamp, which is also why the three nginx-ui instances in the demo
container report identical figures without coordinating.
GeoLite2-City (61 MB) is deliberately not shipped. Country codes are
already accurate offline via the database embedded in cosy; only
province and city are invented.
TestNoDemoBranchesOutsideDemoPackage walks the AST and fails on any
NodeSettings.Demo read outside this package and a listed set of
refusals, so per-module fakes cannot grow back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Introduced `WebSocketTrustedOrigins` setting in `app.example.ini` and corresponding documentation.
- Refactored WebSocket origin checks across multiple API endpoints to utilize the new middleware for improved security.
- Added tests for the new origin validation logic to ensure proper handling of trusted origins and node secret requests.
