Microsoft Entra sign-in, and a self-contained Windows installer

[sameerk27]

What this is

Vigil365 gains Microsoft Entra sign-in, a large amount of dashboard and QA work, and — most of the recent commits — a real installer. It is a big branch (109 commits, ~220 files); the sections below are ordered by what a reviewer most needs to look at.

A self-contained installer

The wizard used to run npm install, npm run build and dotnet publish against the source tree on the customer's server. That made it a guided build rather than an installer: it needed the repo, Node and the .NET SDK on a production box, and produced whatever that machine's toolchain resolved that day instead of the build we tested.

The build moved to release time. scripts/build-installer.ps1 builds the SPA from the lockfile, publishes the API self-contained for win-x64, compresses it into a payload embedded in the installer, and emits a single ~121 MB dist/Vigil365-Setup.exe that needs nothing on the target — no source, no Node, no .NET, not even the runtime. Install is now extraction, with the service stopped first and every zip entry checked against the install root.

Prerequisites went from four to one. Azure CLI remains, only because the wizard registers the Entra application.

Bugs found by running it, not reading it

Each of these produced an install that reported success and did not work:

• The app registered into the wrong tenant. It used whichever tenant the Azure CLI happened to be signed into and never said which. On the machine this was found on, three tenants were in play: the administrator's, the operator's Azure sign-in, and a third one the CLI was actually pointed at. The app was created there as a single-tenant registration, so the intended users could never sign in. The tenant is now derived from the administrator's email, resolved via public OpenID discovery before anything is installed, signed in to explicitly, and verified afterwards.
• The service could never reach SQL. It runs as LOCAL SERVICE with Trusted_Connection, but SQL Express grants sysadmin to BUILTIN\ADMINISTRATORS only, so no login existed for it. The installer now creates the login and database while it still holds administrator rights, scoped to db_owner on that one database.
• DataProtection keys were written under Program Files, which LOCAL SERVICE cannot write. The keyring never persisted, so every restart invalidated anything protected with it — including the Graph secret saved on the Setup page. Moved to ProgramData with an explicit ACL.
• The Windows service was never created. sc was invoked through cmd.exe, which re-parsed the quotes and split the path (binPath=C:\Program plus a stray argument). RunCommand discarded exit codes, so nothing noticed. sc.exe is now called directly, its exit code checked, and the install waits for the service to report RUNNING.
• A fresh database crashed the app on startup. NotificationSettings and GraphConfig are singleton rows whose model fixes the key at 1, but InitialCreate made both keys identity columns by EF convention, so the explicit key was rejected. Existing installs were unaffected because the legacy DDL creates those columns without identity — which is why this only ever appeared on new machines. Both are now ValueGeneratedNever, with a hand-written migration (the scaffolded AlterColumn does not work; SQL Server cannot change IDENTITY in place).
• The app registration was recreated on every run, so re-running the wizard — the documented way to replace a certificate — littered the tenant and stranded whichever registration was configured last.

HTTPS and certificates

Sign-in goes through Entra, which refuses plain http:// redirect URIs for anything but loopback, so HTTPS is not optional once the app is reachable by name. The wizard opens with who needs to reach this: a loopback evaluation install binds 127.0.0.1, needs no certificate and touches no firewall rule; a network install asks for a hostname and takes a certificate from the Windows store, a .pfx, or one it generates and trusts locally.

The store list initially offered Entra MS-Organization-P2P-Access certificates — they carry Server Authentication and a private key, so they passed every structural test while being useless (device GUID subject, untrusted issuer, daily rotation). Machine-identity certificates are now excluded, and a certificate that does not cover the address is labelled and never preselected.

scripts/request-cert.ps1 is new, for publicly-reachable installs that want a real Let's Encrypt certificate.

Reviewer notes

• History was rewritten. installer-bin/ held two committed executables (146 MB and 64 MB) that exceeded GitHub's file limit and blocked every push. They are build output, superseded by the ignored dist/. Stripped from the branch and added to .gitignore. The pre-rewrite history is tagged locally as backup/pre-filter-installer-bin.
• Not addressed: Azure CLI is still required for Entra registration. Removing it means device-code auth and Graph REST from the installer, and would also let installs proceed where the operator lacks rights to create app registrations.
• Verification. Client typecheck clean and 74 tests passing; installer config generated and parsed across all four shapes; installer SQL parse-checked against a real SQL Express; the app confirmed to start against a real database returning HTTP 200 on /health; the shipped exe launches. A full unattended end-to-end install on a clean machine has not been run.

🤖 Generated with Claude Code