EventTag Badge Platform

Every regex candidate is a placeholder, an environment variable reference or application code handling tokens and passwords, and no live key, private key or real connection string was found. Docker Compose requires the passwords to be set, and the committed connection strings use Windows authentication. The remaining issues are weak defaults that ship to buyers: a documented demo password, a documented kiosk staff PIN, and a dev-certificate flag that is enabled by default.

The project uses central package management (Directory.Packages.props) and the README states no vulnerable packages are reported, but no packages.lock.json appears in the file tree, so restores are not reproducible. The actual package versions were not in the digest, so no specific CVE could be confirmed or ruled out.

The documented architecture has per-portal cookie auth, a guard filter (sign-in, event assignment, [RequirePermission]), a hashed kiosk bearer token and BCrypt password hashes. The controller bodies were not in the digest, so per-action guards and id-based ownership checks (event scoping) could not be traced. Several secondary risks are visible: a default kiosk staff PIN, a [hidden] unsalted PIN hash, and an unauthenticated-by-design kiosk API that must be verified

The solution is split into sensible projects (Domain, Infrastructure, Admin, Enabler, Kiosk.Core, Web.Shared) with a documented architecture and a separate Kiosk.Core for testable logic. The main weaknesses are very large single-file browser scripts (designer.js, kiosk-admin.js) and a shipped design-reference folder with duplicated HTML prototypes that adds bulk for buyers.

The solution layout, central package management and Docker setup look coherent, and the demo reset path exists. However, several referenced items (schema.sql, seed.sql, a project file, the upgrade command) are not in the visible tree, and the docs disagree on database script names, so a clean-machine setup may break at the database step. HowToSetup.md and the Dockerfile were not shown, so setup order and SDK pinning could not be fully verified.

The digest shows a single ADO.NET entry point (Db.cs) with parameterized SQL claims and an idempotent upgrade script, which is a good foundation. The repository and schema SQL bodies were not included in the excerpts, so injection safety, WHERE scoping on deletes/updates, per-event tenant scoping and FK indexes could not be confirmed. Several structural issues, such as documentation/file mismatches and a destructive schema script, lower confidence.