@7365admin1/core 3.48.1-staging.149 → 3.48.1-staging.151

package/.changeset/member-write-scope.md

@@ -0,0 +1,60 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the three remaining `/api/members` writes to the membership they name.
+
+`PUT /api/members/id/:id/role/:role/type/:type/org/:org`,
+`PUT /api/members/site` and `PUT /api/members/:id/onboarding/complete` all
+carried `requireAuth` and nothing more, and each took the membership id straight
+out of the request.
+
+**The role write is the sharp one.** A role IS the permission set, so
+re-pointing a membership at another role is an access grant. The service already
+refused to hand a *Seven365 staff* role to a non-staff caller, but a **tenant**
+role was still free: quoting another client's membership id re-pointed it at any
+of that client's roles, their **owner** role included — and equally could demote
+that client's own admin. The `org` in the URL was also what the service used to
+look up owner roles for its "last owner" precondition, so a mismatched one ran
+that safety check against the wrong client's roles entirely.
+
+`PUT /api/members/site` took the membership id **and** the target site from the
+body, so nothing said whose membership, or whose site, either one was — any
+signed-in account could move any client's member onto any estate.
+
+`PUT /api/members/:id/onboarding/complete` took the id from the URL and nothing
+else, so any signed-in account could mark any client's membership onboarded and
+skip that client's onboarding gate.
+
+All three now decide from the **stored** membership, through the
+`requireMemberOrg` helper this controller already uses for
+`PUT /api/members/:id/:status`:
+
+- the organisation recorded on the membership is authorised with
+  `requireOrgAccess` — Seven365 staff, or a live member of that organisation.
+- a membership with **no** organisation is a platform staff row; only Seven365
+  staff may touch it. A missing org is refused, not waved through.
+- the role write additionally refuses when the `org` in the URL disagrees with
+  the one on the membership, so the service's owner-role lookup can no longer be
+  pointed at another client.
+- `PUT /api/members/site` puts the incoming site through `requireSiteReach`, the
+  same rule `/api/vehicles` and `/api/documents` use, so a member cannot be moved
+  onto an estate the caller cannot reach. An unreachable site answers as one that
+  does not exist (404), so site ids cannot be enumerated from the difference.
+
+Guards sit **after** each handler's Joi validation, so a malformed id still
+answers 400 exactly as it does today.
+
+Scope note — deliberately NOT changed here: the four read-by-user routes
+(`GET /api/members/user/:id`, `/users/:id`, `/user/:id/app/:type`,
+`/user/:id/app/:type/org`). `layer-common ServiceProviderMain.vue:922,1320` and
+`InvitationClientForm.vue:324` legitimately read the memberships of a user who
+belongs to a **service provider's** organisation, not to the caller's, and no
+existing helper expresses "an organisation my organisation has engaged". That
+needs a product decision rather than a guess. Every other caller passes its own
+user id. `POST /api/members/direct` and `POST /api/members/verification/:id` are
+also unchanged — the latter is driven entirely by a single-use, expiring
+invitation record and grants the caller nothing.
+
+Nothing changes for a permitted caller: same response shape, same fields, same
+status.

package/.changeset/user-self-scope.md

@@ -0,0 +1,45 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the user record routes to the person themselves, or Seven365 staff — on both `/api/users` and `/api/users/v2`.
+
+Five routes on each mount carried `requireAuth` and nothing more, with the target
+user id taken straight out of the URL:
+
+- `GET /api/users/id/:id` returned any account's name, email, contact and NRIC.
+- `GET /api/users/organization` took the organisation from the caller's own query
+  string, so any signed-in account could page through any client's whole people
+  directory.
+- `PATCH /api/users/birthday/:id` rewrote any account's date of birth.
+- `PATCH /api/users/field/:id` is the sharp one. Its allow-list includes `email`,
+  `nric`, `status` and `defaultOrg`, so pointing it at somebody else's id rewrote
+  **their sign-in address** — and the forgot-password flow then delivers to the
+  new one. That is account takeover, and `status` on the same route disables an
+  account.
+- `PATCH /api/users/password/:id` verifies the current password inside the
+  service, so it was an online **guessing oracle** against any account: a wrong
+  current password and a mismatched confirmation answered differently.
+
+`/api/users/v2` is a separate controller file (`user-v2.controller.ts`) with the
+same routes and the same five holes, so the guard was added to
+`console-authz.util.ts` as `requireSelfOrPlatformStaff` and **both** controllers
+call it — rather than fixing v1 and leaving its twin open.
+
+- the four id-in-URL routes require the id to be the caller's own, or the caller
+  to be Seven365 staff.
+- `GET /api/users/organization` puts the caller-supplied organisation through
+  `requireOrgAccess` before it is used, the same way `GET /api/members` does.
+
+Guards sit after each handler's Joi validation, so a malformed id or a malformed
+value still answers 400 exactly as it does today.
+
+Every caller in the org already satisfies this rule: the account app's
+personal-info screens, the resident mobile app's profile editor, and the sign-in
+and verify-email flows all pass the caller's own id. The one screen that edits
+another person, `layer-common ClientDetailForm.vue:370`, is reached only from
+`web-app-org pages/super-admin/client-list.vue` — the Seven365 staff console —
+which the staff branch covers.
+
+Nothing changes for a permitted caller: same response shape, same fields, same
+status.

package/dist/index.d.ts

@@ -9854,7 +9854,7 @@ declare function MHidAmicoIdentity(value: THidAmicoIdentity): {
     member: ObjectId | undefined;
     serviceProvider: ObjectId | undefined;
     visitor: ObjectId | undefined;
-    type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+    type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
     status: "deleted" | "active" | "inactive";
     metadata: Record<string, unknown>;
     createdAt: string | Date;
@@ -9958,7 +9958,7 @@ declare function useHidAmicoRepo(): {
         member: ObjectId | undefined;
         serviceProvider: ObjectId | undefined;
         visitor: ObjectId | undefined;
-        type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+        type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
         status: "deleted" | "active" | "inactive";
         metadata: Record<string, unknown>;
         createdAt: string | Date;
@@ -10315,7 +10315,7 @@ declare function useHidAmicoService(): {
         member: bson.ObjectId | undefined;
         serviceProvider: bson.ObjectId | undefined;
         visitor: bson.ObjectId | undefined;
-        type: "admin" | "resident" | "contractor" | "unknown" | "visitor" | "staff";
+        type: "admin" | "resident" | "contractor" | "visitor" | "unknown" | "staff";
         status: "deleted" | "active" | "inactive";
         metadata: Record<string, unknown>;
         createdAt: string | Date;