@7365admin1/core 3.49.1-staging.216 → 3.50.1-staging.217

package/.changeset/site-camera-enum-validation.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Constrain site camera `category` and `status` with Joi `.valid()` instead of `.allow()`

package/CHANGELOG.md

@@ -1,5 +1,343 @@
 # @iservice365/core
 
+## 3.50.0
+
+### Minor Changes
+
+- ee5e7dd: Scope the access-management routes that name a card, not a site.
+
+  `access-management-site-scope` closed the routes whose request already carries
+  an estate. Seven routes on the same mount carry none — they reach an access card
+  (or a unit) by `_id` and nothing else — so there was nothing for that rule to
+  read and they were left carrying `requireAuth` alone:
+
+  - `POST /sign-qr` — mints a working door credential. The card number is
+    RSA-encrypted into a QR payload the reader accepts for up to 24 hours when
+    `purpose` is `"vms"`. Any signed-in account could hand itself a valid pass for
+    any card in any estate on the platform.
+  - `PATCH /delete-card` — deactivates a card, which is what stops it opening a
+    door.
+  - `PATCH /nfc-status` — flips a card's status and activation.
+  - `PATCH /visitor-checkout` — releases a visitor's card and writes its history.
+  - `POST /card-replacement` — retires a card and hands its replacement to a unit.
+  - `POST /assign-user` — hands the cards on a unit to a list of people.
+  - `POST /settings` — rewrites an estate's access-management settings, including
+    the address of the Entrypass controller it talks to. This one DOES carry the
+    estate, in the body, and the repository upserts on it; it was simply never
+    checked.
+
+  For the six that name a record, the scope is now decided on the STORED row via
+  `siteReachOf` — the same rule `requireBulletinVideoReach` and
+  `requireEntryPassReach` already apply, and the same underlying `entitleSite`
+  verdict as `requireSiteReach`. `POST /settings` uses `requireSiteReach` on the
+  body's site, exactly as `GET /settings/:site` already does. No new mechanism and
+  no new permission string: reaching the estate is the whole rule, so the
+  contracted agency at the guardhouse, the org-wide manager and a resident reading
+  their own pass are all unaffected.
+
+  Where a write MOVES a card onto a unit (`card-replacement`, `assign-user`) the
+  destination unit is checked as well as the card, so a card cannot be re-parented
+  into an estate the caller cannot reach.
+
+  "Not yours" and "does not exist" answer identically (404), so card ids cannot be
+  enumerated. An id matching no row is refused rather than waved through, and a
+  row naming no estate fails closed. The guards sit after each handler's Joi
+  validation, so malformed input still answers 400 exactly as before.
+
+  `GET /door-access-levels`, `GET /lift-access-levels` and `GET /access-groups`
+  are deliberately NOT changed: they carry no estate and no record, only a
+  caller-supplied `acm_url`, so there is nothing to scope against without changing
+  their request contract. They are recorded as a separate piece of work.
+
+- 042aae6: Scope invitation creation to an organisation the caller can reach, and stop a
+  non-staff caller minting a Seven365 staff invitation on the v1 endpoints.
+
+  Six endpoints took `metadata.org` — and the `app` that becomes the accepted
+  membership's `type` — straight from the request body, behind `requireAuth` and
+  nothing else:
+
+  - `POST /api/auth/invite` (`auth.route.ts:29`)
+  - `POST /api/auth/invite/user` (`auth.route.ts:30`)
+  - `POST /api/auth/invite/member` (`auth.route.ts:31`)
+  - `POST /api/auth/invite/service-provider/with-org` (`auth.route.ts:33`)
+  - `POST /api/auth/v2/invite` (`auth-v2.route.ts:22`)
+  - `POST /api/auth/v2/invite/organization` (`auth-v2.route.ts:23`)
+
+  Two things followed from that.
+
+  **The organisation.** The roles/members fix lets somebody holding an invitation
+  into an organisation reach it, because the client onboarding wizard needs that.
+  An attacker could therefore issue themselves the invitation the gate asks for —
+  one authenticated write naming any victim organisation — and walk straight back
+  into the chain that fix closed.
+
+  **`app`.** "admin" is what makes a membership Seven365 staff, and
+  `member.service.ts acceptInvite` writes `type: invite.metadata.app` verbatim.
+  `createMemberDirect` already refuses a staff membership from a non-staff caller;
+  the invitation road to the same place was open on the v1 mounts. The v2 twin
+  asked; the v1 mounts, which are the ones the web apps call, did not.
+
+  All six now call `requireInviteReach` (`utils/console-authz.util.ts`): Seven365
+  staff, a live member of the organisation, or somebody holding an invitation into
+  it — plus `requirePlatformStaff` when the invitation names the staff app. An
+  invitation that names no organisation is unchanged; it grants no organisation,
+  exactly as an org-less `GET /api/roles` does. The two service-provider invites
+  that already resolved their caller from the session are unchanged.
+
+- dc7ab90: Scope the organisation list to the caller, and put the promo-code list behind the staff gate.
+
+  `GET /api/organizations` and `GET /api/promo-codes` performed no authorization
+  at all — `requireAuth` and nothing more — while every sibling handler in the
+  same two files guarded. So any signed-in account on the platform, a resident or
+  a cleaner included, could page through the name, e-mail, nature and status of
+  **every Seven365 client**, and read off **every discount code** we have ever
+  minted, with its rate and its expiry, and then redeem whichever is worth most.
+
+  The two rules are different, because the callers are different.
+
+  **`GET /api/organizations` is now a SCOPE, not a refusal.** Seven365 staff see
+  every organisation exactly as before; anybody else sees the organisations they
+  hold a live membership of, plus any registered under their own verified account
+  e-mail. The e-mail half is not decoration: `web-app-main
+pages/verify/email/index.vue:322` — the org-owner self-signup — lists
+  organisations to find the one it created a line earlier, at which point that
+  brand-new client owner is a member of nothing. Refusing them would have traded
+  the leak for a broken signup. The comparison is the one
+  `getOrgsByEmail` already makes, against the address on the caller's own `users`
+  row; nothing the caller sends takes part in it. It also removes a real bug from
+  that flow: the page takes `items[0]` of a newest-first list, so two client
+  owners signing up in the same moment could be handed each other's organisation
+  as their `defaultOrg`.
+
+  The scope is part of the Redis cache key as well as the query, so one caller's
+  narrowed page is never replayed to the next, and `countDocuments` runs the
+  scoped query so pagination cannot walk past the scope.
+
+  **`GET /api/promo-codes` is Seven365 staff only,** together with
+  `GET /api/promo-codes/id/:id`, which is the same disclosure one record at a
+  time. Both are read solely by the staff console. A client at checkout is
+  unaffected: `web-app-org pages/checkout.vue` and
+  `subscription/manage-seats.vue` type a code and validate it through
+  `GET /api/promo-codes/code`, which stays signed-in-only and is untouched.
+
+- c7b57f5: Make revoking somebody's access actually end their session.
+
+  A session in this product is an opaque `sid` whose only record of truth is a
+  Redis key `sid:<sid>` holding a copy of the user document. `requireAuth`
+  authenticates a request by finding that key and nothing else — it never reads
+  the database — and it re-`EXPIRE`s the key to four hours on every request, so a
+  session that is in use never ages out on its own.
+
+  **Signing out was never the problem.** `logout()` deletes the key, so a
+  signed-out session is refused; that half already worked. Every other way access
+  is taken away did not.
+
+  **Suspending somebody changed a column and nothing else.**
+  `suspendResidentById` writes `users.status = "suspended"` through
+  `updateUserFieldById`, which cleared the user-document cache and left the
+  `sid:` key untouched. The person carried on working, and every request they made
+  pushed the four-hour expiry out another four hours. On top of that,
+  `refreshToken()` minted a **brand new** session through `issueSession` with no
+  account-status check at all — the mobile refresh token is seven days and
+  rotating, so a suspended account's phone could keep issuing itself fresh
+  sessions indefinitely. Suspension was not a delay, it was a no-op for anyone
+  already signed in.
+
+  **Two of the statuses the product writes were never refused at sign-in either.**
+  Both `login()`s checked `suspended` and `pending` only, so `rejected` (written by
+  `reviewPerson`, whose email is the one that hides the login link) and `deleted`
+  (`UserStatus.DELETED`, the soft-delete marker) could sign in fresh with a
+  password.
+
+  The fix is the two halves of that, at the two choke points that already exist:
+
+  - **Minting refuses a non-live account** — `assertAccountLive` in `issueSession`
+    in both auth services, which is the one place every sign-in path in this
+    package goes through (login and mobile refresh, v1 and v2), for the same
+    reason `assertOrganizationNotSuspended` lives there.
+  - **Revoking destroys what already exists** — `revokeAccountAccess` from
+    `updateUserFieldById`, the only path in either user repository that writes
+    `users.status`. It deletes every `sid:` key the person holds and every refresh
+    token in `tokens`, so nothing can mint a replacement.
+
+  Finding every session a person holds needs an index: `users.sid` only ever
+  remembers the most recent sign-in, v2 never writes it, and nothing reads it — a
+  fix built on that column would revoke the phone and leave the browser signed in.
+  The index is a Redis set (`user-sessions:<userId>`), so there is no schema
+  change and no migration; `users.sid` stays as the fallback that catches v1
+  sessions minted before the set existed.
+
+  The blocking statuses are `suspended`, `pending`, `rejected` and `deleted`, as a
+  deny-list — `status` is optional on the model and legacy rows carry `""` or no
+  field at all, and an allow-list would lock every one of them out. `resubmit` is
+  deliberately live: that email keeps the login link, because resubmitting the
+  application is done signed in.
+
+  Nothing is logged out by deploying this — no existing session is touched, and
+  the two sign-in messages for `suspended` and `pending` are unchanged, because
+  `login()` still checks those two itself before minting. What changes for a
+  signed-in user is only that a `rejected` or soft-deleted account can no longer
+  obtain a session, and that a suspension now takes effect at once rather than
+  never.
+
+- 6cbc3fa: Stop a deleted role from conferring Seven365 identity, and protect the seeded
+  platform-owner role.
+
+  Two defects on the roles collection, both of which made an ordinary
+  administrative action do the opposite of what it says.
+
+  **Deleting somebody's admin role did not take their access away.**
+  `deleteRole` (`role.repo.ts`) is a SOFT delete: it sets `{ status: "deleted" }`
+  and leaves the document in place. `isSuperAdmin` and `isPlatformOwner`
+  (`super-admin.util.ts`) read that role by `_id` alone, and so did the second
+  staff derivation in `resolveInviteActor` (`invite-actor.util.ts`). So the
+  ordinary way to revoke a Seven365 staff account — delete the admin role it sits
+  on — left the account platform staff: `requirePlatformStaff` still passed, and
+  staff identity is the bypass on `requireOrgAccess`, on `requireSiteReach` and on
+  organisation suspension. `getUserPermissions` (`permission.util.ts`) always
+  filtered on status, which is why the same account lost every permission and kept
+  the identity that makes permissions unnecessary.
+
+  All three identity derivations now require a live role. "Live" is spelled
+  `$ne: "deleted"` — the test already applied to the `members` row in the same
+  functions — rather than `status: "active"`. Roles carry exactly two statuses in
+  this package: `MRole` has defaulted `status` to `"active"` since the model's
+  first commit and every insert goes through `addRole` -> `new MRole()`, and
+  `"deleted"` is written by `deleteRole` alone (no API can send `status` on a
+  role; `updateRole` takes a name and permissions only). The two spellings
+  therefore agree on every row this package can write and differ only on a
+  pre-package row carrying no `status` at all, where `$ne` keeps that account
+  working and `"active"` would silently strip its console access. No migration is
+  implied.
+
+  **The seeded platform-owner role could be deleted, and nothing put it back.**
+  `createDefaultUser()` seeds one org-less `{ type: "admin", default: true }`
+  role, and that pair is the whole of `isPlatformOwner`. Deleting it is a one-way
+  door: `getRoles` lists active rows only, so it disappears from the roles screen,
+  and at the next boot `createDefaultUser` finds the deleted row by name and type
+  and reuses it rather than seeding a fresh one — leaving the owner account with
+  no permissions and no way to restore the role through the product. The Delete
+  and Edit buttons on the roles screen
+  (`layer-common components/RolePermissionMain.vue`) both reached it.
+
+  `role.repo.ts` now refuses to delete, rename or rewrite the permissions of that
+  role. The guard sits in the repository because all four write paths pass through
+  those three functions: `role.service.deleteRole`,
+  `role.service.deleteWithReassignments` (which deletes inside a transaction after
+  moving every member off), and the two `role.controller` edit paths that call the
+  repository directly — a guard in the service would have covered the deletes and
+  missed the edits. A CLIENT's own "owner" role is also `default: true`
+  (`subscription.service` writes two per new client) but is typed `organization`
+  or the org's nature, so requiring the platform staff type leaves every client's
+  own role editable exactly as before.
+
+  No new authorization mechanism is introduced, and no route's authentication or
+  permission requirements change.
+
+- ebdfd23: Scope the role list, role creation and direct membership creation to an
+  organisation the caller can actually reach.
+
+  Two endpoints took the organisation straight from the request, and they chained
+  into a cross-tenant escalation that any signed-in account could run:
+
+  1. `GET /api/roles?org=<any org id>` listed that client's roles with their ids —
+     `role.controller.ts getRoles` made no scope call at all and `role.repo.ts`
+     put the caller's query string into `{ status: "active", org }`.
+  2. `POST /api/members/direct` wrote a membership into whatever `orgId` the body
+     named (`member.controller.ts createMemberDirect` validated the shape and
+     nothing else).
+  3. `member.model.ts` writes `status: value.status || "active"`, so that row is
+     live on insert.
+  4. `resolveInviteActor` then reports that organisation in the caller's `orgIds`,
+     which is exactly what `requireOrgAccess` asks for — the gate that every
+     role, member, people, site and camera fix in the 3.49.0 wave depends on.
+
+  So a resident, a visitor's contact or a cleaner could enrol itself as an active
+  member of any client organisation and inherit that client's reach. The
+  escalation to Seven365 platform owner was closed earlier; this is the same
+  attack scoped down one level, at the tenant.
+
+  The decision is a new `requireOrgReach` in `console-authz.util.ts`: **Seven365
+  staff, a live member of the organisation, or somebody holding an invitation into
+  it.** The third clause is not a convenience — three live flows legitimately
+  reach an organisation before any membership exists, and a flat membership test
+  would break all of them:
+
+  - the service provider signing in against a `service-provider-invite`, who looks
+    up the customer's "Admin Service Provider" role and creates it when the
+    customer has none (`web-app-main pages/sign-in.vue:298,311,428`);
+  - the admin member finishing sign-up from a `member-invite`
+    (`web-app-main pages/verify/email/index.vue:462`);
+  - the client owner walking the onboarding wizard
+    (`web-app-org pages/onboarding/getting-started/index.vue`).
+
+  All three hold a verification addressed to their own email whose `metadata.org`
+  is the organisation being reached, and that invitation is the relationship the
+  rule tests (`hasOrgInvitation` in `invite-actor.util.ts`). The address is read
+  from the `users` row for the session id, never from the request; both the
+  ObjectId and the older string shape of `metadata.org` are matched, the same pair
+  `completePendingInvites` matches on; and only the three invitation types count,
+  so a password-reset code opens nothing.
+
+  Where the check now runs:
+
+  - `GET /api/roles` — when the caller sends an `org`. With no `org` the query is
+    unchanged and still matches only the ORG-LESS platform roles, which is what
+    every invitation screen asks for and is not a tenant's data.
+  - `POST /api/roles` and `POST /api/roles/v2` — on the `org` the new role is
+    filed under. Both mounts, because `/v2` is a separate controller and gating
+    one would leave the hole reachable by adding `/v2` to the URL.
+  - `POST /api/members/direct` — enrolling YOURSELF needs reach, so an invitation
+    counts; enrolling ANYBODY ELSE needs `requireOrgAccess`, real membership. The
+    onboarding wizard's second call, which adds the Seven365 support account,
+    always follows the caller's own row, so it passes.
+
+  `requireOrgAccess` itself is untouched. The invitation clause is additive and
+  lives in a separate function — widening the shared one would hand all 78 of its
+  mounts to anybody holding an invitation.
+
+  Proved end to end in `test/e2e/org-scoping-roles-members.e2e.test.mjs`: 13 of
+  its 23 cases fail on the code before this change and all 23 pass after, while
+  every "must keep working" case — the caller's own org, the org-less platform
+  list, a member enrolling a colleague, staff reaching any client, and the whole
+  invited-newcomer flow — passes on both.
+
+### Patch Changes
+
+- 7bf8130: Decide the HRM Labs location server-side, so an entitled caller cannot read
+  another site's roster.
+
+  `requireSiteReach(req, siteId, ATTENDANCE_READ)` guards all four manpower-attendance
+  reads, but `siteId` is not what selects the roster — it only picks the local
+  `manpower-settings` row. The roster is selected by `locationName`, the field HRM Labs
+  is asked for, and that came straight from the request body's `siteName` with nothing
+  checking it against `siteId`.
+
+  So the two could disagree. A caller entitled to site A could send site A's `siteId`,
+  pass the guard, and pair it with **another** site's `siteName` — and read that site's
+  employee roster back: names, staff numbers, job titles, NRICs
+  (`identificationNumber`) and the check-in/check-out photographs. The exposure had been
+  narrowed from anyone on the internet to any signed-in account; this closes it.
+
+  The location now comes from `config.siteName`, the settings row the caller was already
+  entitled to, via one `locationOf()` helper called in each of the four functions. That
+  is the same source the screen reads from: the security app fills `siteId` and
+  `siteName` from one HRM Labs site-list entry (`site.id` / `site.text`),
+  `manpowerMonitoringSchema` makes `siteName` required on both write paths, and
+  `TManpowerMonitoringUpdate` cannot change it — so for every legitimate row the pair
+  already agreed and the server simply stops asking.
+
+  A row with no stored name is refused rather than falling back to the body; a fallback
+  would re-open the hole for exactly the rows an attacker would want to name for
+  themselves.
+
+  Nothing legitimate changes. The Joi schemas still accept `siteName`, so no client needs
+  a coordinated release — it is accepted and ignored. The three internal callers
+  (`manpower.event.ts` and the two `cron.util.ts` sweeps) get more reliable, not less:
+  they were passing `manpower-remarks.siteName`, which that model marks optional.
+
+- 0be47d5: Scope the "my memberships" reads and the preloved marketplace to the record's stored owner.
+
 ## 3.49.0
 
 ### Minor Changes

package/dist/index.js

@@ -19390,10 +19390,28 @@ var schemaUpdateSiteCamera = import_joi20.default.object({
     then: import_joi20.default.required(),
     otherwise: import_joi20.default.optional().allow(null, "")
   }),
-  category: import_joi20.default.string().allow("standard", "resident", "visitor").required(),
+  /**
+   * `.valid()`, NOT `.allow()` - the same defect already fixed on `type` in
+   * `schemaSiteCamera` below, on the two
+   * remaining fields where the stored value is safe to constrain.
+   *
+   * `.allow()` whitelists ADDITIONAL values on a validator that already accepts
+   * every string, so these three lines have never rejected anything. Measured
+   * on the staging `site.cameras` collection (22 rows, 2026-08-26): `category`
+   * is only ever standard|resident|visitor and `status` only ever
+   * active|inactive, with no nulls, blanks or missing fields - and the only two
+   * write callers in the estate (layer-common `CameraForm.vue` and
+   * `iservice365-mobile-app-security`) offer exactly those values.
+   *
+   * `direction` is deliberately left on `.allow()`: `CameraForm.vue` also
+   * offers "visitors" and "residents", which are outside the intended
+   * entry|exit|both|none set, so constraining it would 400 two of the form's
+   * own five options. That mismatch needs a product decision, not a schema edit.
+   */
+  category: import_joi20.default.string().valid("standard", "resident", "visitor").required(),
   guardPost: import_joi20.default.number().integer().optional(),
   direction: import_joi20.default.string().optional().allow("entry", "exit", "both", "none"),
-  status: import_joi20.default.string().optional().allow("active", "inactive", "deleted"),
+  status: import_joi20.default.string().optional().valid("active", "inactive", "deleted"),
   name: import_joi20.default.string().optional().allow(null, "")
 });
 var schemaSiteCamera = import_joi20.default.object({
@@ -19426,10 +19444,11 @@ var schemaSiteCamera = import_joi20.default.object({
    * today. Every client in the estate already sends the lower-case pair.
    */
   type: import_joi20.default.string().trim().lowercase().valid("ip", "anpr").required(),
-  category: import_joi20.default.string().allow("standard", "resident", "visitor").required(),
+  /** See the note on `schemaUpdateSiteCamera` for why `direction` stays as it is. */
+  category: import_joi20.default.string().valid("standard", "resident", "visitor").required(),
   direction: import_joi20.default.string().required().allow("entry", "exit", "both", "none"),
   guardPost: import_joi20.default.number().integer().optional(),
-  status: import_joi20.default.string().optional().allow("active", "inactive", "deleted"),
+  status: import_joi20.default.string().optional().valid("active", "inactive", "deleted"),
   name: import_joi20.default.string().optional().allow(null, ""),
   createdAt: import_joi20.default.date().optional(),
   updatedAt: import_joi20.default.date().optional(),