@7365admin1/core 3.47.1-staging.136 → 3.47.1-staging.138

package/.changeset/customer-site-org-scope.md

@@ -0,0 +1,48 @@
+---
+"@7365admin1/core": minor
+---
+
+Scope `/api/customer-sites` to the organisations on the record.
+
+Every route on this module except the pre-login invite acceptance carried
+`requireAuth` and nothing more, and took the organisation straight out of the
+query string or the body (`customer-site.controller.ts`). Two things followed
+from that, and both are closed here.
+
+`POST /api/customer-sites` is not merely an engagement record: it CREATES A SITE
+inside whatever `siteOrg` the body names, and writes that site onto the
+organisation as its default when it has none
+(`customer-site.service.ts:77-111`). Any signed-in account on the platform — a
+resident, a cleaner, a guard — could therefore plant a site inside any client.
+
+A `customer.sites` row is also the cross-organisation access grant itself: the
+"engaged agency" branch of `resolveSiteAccess` reads it to decide who may reach
+a site's cameras, HID readers and residents
+(`camera-view.service.ts:325-341`). Being able to write, edit or delete those
+rows by id was being able to grant yourself reach into another client's estate,
+or revoke a contractor's.
+
+The caller is now resolved from the session and the decision made before
+anything is read or written:
+
+- `POST /` requires `requireOrgAccess` on the body's `org`, and on `siteOrg`
+  too when it names a different organisation — because that is where the new
+  site lands. The Add / Edit Site form sends the same id for both
+  (`web-app-org components/SiteForm.vue:397-402`).
+- `GET /` requires `requireOrgAccess` on the `org` filter the caller sends.
+- `GET /:id`, `PUT /:id` and `DELETE /:id` load the row first and decide from
+  the row's own `org` and `siteOrg` — Seven365 staff, or a live member of
+  EITHER side of the engagement. Either, not one: the estate's manager reaches
+  the row through `siteOrg` and the contracted agency reaches the same row
+  through `org`, so scoping to one side would break the other's screen.
+- `GET /service-provider/:id` takes a SITE id, and uses `entitleSite` — the
+  same site-reach rule the camera, HID and people modules already use, so an
+  agency contracted to a site still lists who else works there.
+
+`POST /invite/:id` is unchanged and still reachable with no session: an invited
+organisation accepts before it has an account (`web-app-main pages/sign-in.vue:182`).
+
+No new authorization mechanism is introduced. `requireOrgAccess` and
+`entitleSite` are the helpers the member, role, people, camera and HID paths
+already use, and the "either side" test is `resolveInviteActor` asked about two
+organisations in one round trip rather than two.

package/.changeset/verification-status-transition.md

@@ -0,0 +1,35 @@
+---
+"@7365admin1/core": minor
+---
+
+Restrict the unauthenticated invitation-status write to the one transition its
+callers actually perform.
+
+`PATCH /api/auth/verification/status` (`API-core auth.route.ts:36`) carries no
+middleware, and it cannot be given any: every caller is an invitation-landing
+page opened from an emailed link **before an account exists** —
+`web-app-main` `pages/verify/invitation/[id].vue`,
+`pages/verify/service-provider/[id].vue`,
+`pages/verify/service-provider-invite/[id].vue` and
+`pages/sign-up-invite/service-provider/index.vue`, all through
+`layer-common composables/useLocalAuth.ts:130`. Adding `requireAuth` would break
+invitation acceptance for everybody, including the shipped clients.
+
+What is restricted instead is what an anonymous caller may *do*. Each of those
+pages calls `GET /auth/verify/:id` first, and `verify`
+(`verification.service.ts:661-690`) already refuses an invitation that is
+expired, cancelled or complete — so the only transition a real caller ever
+performs is `pending -> complete`. Accepting the other three states let anyone
+who learned an invitation id:
+
+- set a used invitation back to `pending` and replay it,
+- revive a `cancelled` or `expired` invitation, or
+- burn somebody else's pending invitation by marking it `complete` before they
+  opened the email.
+
+The handler now accepts only `complete`, loads the invitation and requires it to
+be `pending`. Completing an already-complete invitation still answers 200 so a
+page that calls this twice is not broken. Cancelling an invitation on purpose
+keeps its own session-protected endpoint,
+`PUT /api/verifications/:id/cancel` (`verification.route.ts:13`), so no
+capability is removed.

package/dist/index.js

@@ -19440,7 +19440,7 @@ function useVerificationController() {
     updateStatusById: _updateStatusById,
     cancelUserInvitation: _cancelUserInvitation
   } = useVerificationService();
-  const { getVerifications: _getVerifications } = useVerificationRepo();
+  const { getVerifications: _getVerifications, getById: _getVerificationById } = useVerificationRepo();
   async function createUserInvite(req, res, next) {
     const payload = { ...req.body };
     const validation = import_joi21.default.object({
@@ -19825,7 +19825,7 @@ function useVerificationController() {
   async function updateVerificationStatus(req, res, next) {
     const validation = import_joi21.default.object({
       id: import_joi21.default.string().hex().required(),
-      status: import_joi21.default.string().valid("pending", "complete", "expired", "cancelled").required()
+      status: import_joi21.default.string().valid("complete").required()
     });
     const { error } = validation.validate(req.body);
     if (error) {
@@ -19835,6 +19835,23 @@ function useVerificationController() {
     }
     try {
       const { id, status } = req.body;
+      const verification = await _getVerificationById(id);
+      if (!verification) {
+        next(new import_node_server_utils47.BadRequestError("Verification not found."));
+        return;
+      }
+      if (verification.status === "complete") {
+        res.json({ message: "Successfully updated verification status." });
+        return;
+      }
+      if (verification.status !== "pending") {
+        next(
+          new import_node_server_utils47.BadRequestError(
+            `Verification is ${verification.status} and cannot be completed.`
+          )
+        );
+        return;
+      }
       const result = await _updateStatusById(id, status);
       res.json({ message: result });
       return;
@@ -39590,6 +39607,15 @@ function useCustomerSiteService() {
 // src/controllers/customer-site.controller.ts
 var import_joi58 = __toESM(require("joi"));
 var import_node_server_utils116 = require("@7365admin1/node-server-utils");
+async function requireEitherOrg(req, ...orgs) {
+  const wanted = orgs.map((org) => org?.toString?.() ?? "").filter((org) => Boolean(org));
+  const actor = await resolveInviteActor(callerId(req));
+  if (actor.isSuperAdmin)
+    return;
+  if (wanted.length === 0 || !wanted.some((org) => actor.orgIds.includes(org))) {
+    throw new import_node_server_utils116.UnauthorizedError("Not authorized.");
+  }
+}
 function useCustomerSiteController() {
   const {
     getAll: _getAll,
@@ -39607,6 +39633,10 @@ function useCustomerSiteController() {
       return;
     }
     try {
+      await requireOrgAccess(req, value.org);
+      if (value.siteOrg && value.siteOrg.toString() !== value.org?.toString()) {
+        await requireOrgAccess(req, value.siteOrg);
+      }
       const data = await _add(value);
       res.status(201).json(data);
       return;
@@ -39674,6 +39704,7 @@ function useCustomerSiteController() {
       }
     });
     try {
+      await requireOrgAccess(req, org);
       const data = await _getAll({
         search,
         page,
@@ -39705,6 +39736,13 @@ function useCustomerSiteController() {
       return;
     }
     try {
+      const actor = await resolveInviteActor(callerId(req));
+      if (!actor.isSuperAdmin) {
+        await useCameraViewService().entitleSite({
+          siteId: site,
+          userId: actor.id
+        });
+      }
       const data = await _getBySiteAsServiceProvider(site);
       res.json(data);
       return;
@@ -39726,6 +39764,7 @@ function useCustomerSiteController() {
     }
     try {
       const data = await _getById(id);
+      await requireEitherOrg(req, data?.org, data?.siteOrg);
       res.json(data);
       return;
     } catch (error2) {
@@ -39744,6 +39783,8 @@ function useCustomerSiteController() {
       return;
     }
     try {
+      const existing = await _getById(id);
+      await requireEitherOrg(req, existing?.org, existing?.siteOrg);
       const data = await _updateCusSiteById(id, req.body);
       res.json(data);
       return;
@@ -39755,6 +39796,8 @@ function useCustomerSiteController() {
   async function deleteById(req, res, next) {
     const id = req.params.id;
     try {
+      const existing = await _getById(id);
+      await requireEitherOrg(req, existing?.org, existing?.siteOrg);
       const data = await _deleteById(id);
       res.json(data);
       return;