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

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;