@7365admin1/core 3.47.1-staging.135 → 3.47.1-staging.137

package/.changeset/vehicle-approve-permission-prefix.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Check the vehicle-approval permission under the resource name the catalogues
+actually grant.
+
+When a security agency adds a vehicle, the vehicle is parked at `PENDING` unless
+the caller may approve one. `vehicle.service.ts:125` asked for
+`vehicleManagement:approve-vehicle`, but every catalogue that can grant a
+permission spells that resource `vehicle-mgmt` — `web-app-security`
+`composables/useSecurityPermission.ts:87,111`, `web-app-org`
+`composables/usePropertyPermission.ts:312`, `ma-mobile-app`
+`src/features/permissions/permission.catalog.ts:7`, `isecure365-mobile-app`
+`src/features/permissions/permission.catalog.ts:32`. Only the prefix differed,
+so the string checked here was one no role could hold and the bypass could never
+be reached by granting the permission — the agency's vehicles stayed pending
+however the role was set up. `vehicleManagement:` appears nowhere else in any
+repository in the organisation.
+
+The `*` wildcard branch is untouched, so a role holding all permissions behaves
+exactly as before; this only makes the specific grant work as intended.

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;
@@ -32187,7 +32204,7 @@ function useVehicleService() {
       user,
       org: value.org
     });
-    const hasSecurityBypass = addedBySecurity && Array.isArray(userPermissions) && (userPermissions.includes("*") || userPermissions.includes("vehicleManagement:approve-vehicle"));
+    const hasSecurityBypass = addedBySecurity && Array.isArray(userPermissions) && (userPermissions.includes("*") || userPermissions.includes("vehicle-mgmt:approve-vehicle"));
     if (hasSecurityBypass) {
       addedByPM = true;
     }