Every route had to remember to add the business filter to every query;
nothing stopped one that forgot. The audit for this change found several
that had: the M-Pesa status re-check, the stock ledger's duplicate checks,
the daily-inventory and branch-price upserts, a cash-sale replay lookup,
several load-by-id lookups, and every populate().
- tenantGuard: a Mongoose plugin on all ten business-scoped models. Any
find/update/delete/count/distinct, or an aggregate whose first stage is
not a $match, that does not pin exactly one businessId throws
TenantScopeError before reaching the database ($in, $exists and other
operators do not count).
- crossTenant("reason", fn): the explicit, documented exemption for the
queries that must span businesses - login's email lookup, refresh and
invite-token lookups, the M-Pesa callback, the platform console and the
maintenance scripts. git grep crossTenant lists them all.
- scopedPopulate: populated branch, product and staff names are also
restricted to the business.
- Every flagged query site now names the business (or is exempted with a
reason).
- Tests: a check that every model with a businessId field carries the
guard; the guard refusing unscoped queries of every kind; and a route
sweep where business A sends business B's ids to every read route
(nothing of B's comes back) and every write route (all refused, B's
data unchanged). Test-side database inspections go through db(), an
explicit test exemption. Removing one route's business filter makes the
suite fail.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One person could not work for two businesses, and signup and staff
creation told anyone whether an email or phone was registered anywhere
on the platform.
- User email and phone are now unique per business: indexes on
(businessId, email) and (businessId, phoneNumber). Duplicate checks in
signup and branch-manager creation are scoped to the business, so they
no longer reveal other businesses' users.
- Login finds the email in every business and checks the password
against each account. One match signs straight in; several return 300
with the businesses to choose from, and the login page shows a picker.
A wrong password returns the same 401 as before and reveals nothing;
failures count against each candidate account, and a correct password
only resets the accounts it opens.
- Platform-operator access now also needs a platformAdmin flag on the
account. With per-business emails, an email match alone would have let
any owner create a staff account with the operator's email and open the
cross-tenant console. The flag is only set by the seed and the
migration; removing the email from PLATFORM_ADMIN_EMAILS still revokes.
- npm run migrate:identity flags today's operators (while each listed
email still matches one account) and syncs the User indexes, dropping
the old unique email_1 and phoneNumber_1. Checked against a database in
the old shape; safe to re-run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>