@7365admin1/core 3.48.1-staging.150 → 3.48.1-staging.152

package/.changeset/service-provider-record-scope.md

@@ -0,0 +1,39 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope the service provider record routes to the site the engagement works on.
+
+A `site.service-providers` row is an ENGAGEMENT: a provider organisation attached
+to one client's site. Two routes took its id straight out of the URL with
+`requireAuth` and nothing more, so any signed-in account could use them against
+any client:
+
+- `GET /api/service-providers/:id` returned any client's engagement — provider
+  name, category, contact email and the site it works on.
+- `PATCH /api/service-providers/:id/status` suspended or reactivated it.
+  Suspending an engagement stops that provider's guards and cleaners reaching the
+  estate; reactivating one puts them back.
+
+Both now decide from the **site stored on the row**, through the existing
+`requireSiteReach` rule that `/api/vehicles` and `/api/documents` already use.
+That rule admits both sides of the engagement: the client, and the contracted
+provider whose reach comes from `customer.sites` rather than from a membership in
+the client's organisation.
+
+An engagement the caller cannot reach answers exactly as one that does not exist
+(404), so ids cannot be enumerated from the difference. A row carrying no site at
+all is refused, not waved through. Guards sit after each handler's Joi
+validation, so a malformed id or status still answers 400 exactly as today.
+
+Scope note — deliberately NOT changed here: the four list routes
+(`GET /api/service-providers`, `/name`, `/category`,
+`/org/:serviceProviderOrgId/type/:type`) and `GET /provider/:provider/org/:org`.
+Their `orgId`, `siteId` and `serviceProviderOrgId` are optional filters the
+caller sends, and `layer-common useServiceProvider.ts` defaults every one of them
+to an empty string, so it is not yet established which callers depend on the
+unfiltered list. That is the same open question as the site-less
+`GET /api/vehicles` and needs a product decision rather than a guess.
+
+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.js

@@ -18153,6 +18153,13 @@ async function requirePlatformStaff(req) {
   }
   return id;
 }
+async function requireSelfOrPlatformStaff(req, userId) {
+  const id = callerId(req);
+  const target = userId?.toString() ?? "";
+  if (id && target && target === id)
+    return id;
+  return await requirePlatformStaff(req);
+}
 async function requireOrgAccess(req, orgId) {
   const id = callerId(req);
   if (!id)
@@ -18200,6 +18207,7 @@ function useUserController() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       const user = await _getById(_id);
       res.json(user);
       return;
@@ -18228,6 +18236,7 @@ function useUserController() {
     const status = req.query.status ?? "active";
     const organization = req.query.organization ?? "";
     try {
+      await requireOrgAccess(req, organization);
       const data = await _getUsersByOrgId({
         search,
         page,
@@ -18373,6 +18382,7 @@ function useUserController() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       const message = await _updateBirthday({ _id, ...payload });
       res.json({ message });
       return;
@@ -18414,6 +18424,7 @@ function useUserController() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       let message;
       if (payload.field === "plateNumber") {
         message = await updatePlateNumberByUserId(
@@ -18455,6 +18466,7 @@ function useUserController() {
     const newPassword = req.body.newPassword ?? "";
     const passwordConfirmation = req.body.passwordConfirmation ?? "";
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       await _updatePasswordById(
         _id,
         currentPassword,
@@ -32550,6 +32562,7 @@ function useServiceProviderController() {
     }
     try {
       const data = await _getServiceProviderById(_id);
+      await requireSiteReach(req, data?.siteId?.toString());
       res.json(data);
       return;
     } catch (error2) {
@@ -32613,6 +32626,8 @@ function useServiceProviderController() {
       return;
     }
     try {
+      const existing = await _getServiceProviderById(value.id);
+      await requireSiteReach(req, existing?.siteId?.toString());
       await _updateStatusById(value.id, value.status);
       res.json({ message: "Service provider status updated successfully." });
       return;
@@ -80951,6 +80966,7 @@ function useUserControllerV2() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, value);
       const user = await _getById(value);
       res.json(user);
       return;
@@ -81013,6 +81029,7 @@ function useUserControllerV2() {
     if (error)
       return rejectValidation(error, next);
     try {
+      await requireOrgAccess(req, value.organization);
       res.json(
         await _getUsersByOrgId({
           search: value.search ?? "",
@@ -81111,6 +81128,7 @@ function useUserControllerV2() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       const message = await _updateBirthday({ _id, ...payload });
       res.json({ message });
       return;
@@ -81142,6 +81160,7 @@ function useUserControllerV2() {
       return;
     }
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       const message = await _updateUserFieldById({ _id, ...payload });
       res.json({ message });
       return;
@@ -81172,6 +81191,7 @@ function useUserControllerV2() {
     const newPassword = req.body.newPassword ?? "";
     const passwordConfirmation = req.body.passwordConfirmation ?? "";
     try {
+      await requireSelfOrPlatformStaff(req, _id);
       await _updatePasswordById(
         _id,
         currentPassword,