@oneuptime/common 12.0.8 → 12.0.9

package/Server/Services/UserPushService.ts

@@ -2,7 +2,12 @@ import CreateBy from "../Types/Database/CreateBy";
 import DeleteBy from "../Types/Database/DeleteBy";
 import { OnCreate, OnDelete } from "../Types/Database/Hooks";
 import DatabaseService from "./DatabaseService";
+import UserNotificationRuleService, {
+  NotificationDeletionImpact,
+  NotificationMethodChannel,
+} from "./UserNotificationRuleService";
 import BadDataException from "../../Types/Exception/BadDataException";
+import ObjectID from "../../Types/ObjectID";
 import PositiveNumber from "../../Types/PositiveNumber";
 import PushDeviceType from "../../Types/PushNotification/PushDeviceType";
 import UserPush from "../../Models/DatabaseModels/UserPush";
@@ -62,6 +67,30 @@ export class Service extends DatabaseService<UserPush> {
     return { carryForward: null, deleteBy };
   }
 
+  /**
+   * What this user would lose if this device were deleted. Ask BEFORE calling
+   * delete; nothing here refuses anything.
+   *
+   * Note what the hook directly above does NOT do. The other six method
+   * services delete their notification rules themselves; this one leaves it
+   * entirely to UserNotificationRule.userPushId, which is onDelete: "CASCADE".
+   * The rules go either way — the database sees to it — so the loss is exactly
+   * as large here as everywhere else, and it is even less visible from the
+   * code. Push is also the channel a responder is most likely to have several
+   * of and to prune casually, one retired handset at a time.
+   */
+  @CaptureSpan()
+  public async getDeletionImpact(data: {
+    itemId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<NotificationDeletionImpact> {
+    return UserNotificationRuleService.getNotificationMethodDeletionImpact({
+      projectId: data.projectId,
+      methodType: NotificationMethodChannel.Push,
+      methodId: data.itemId,
+    });
+  }
+
   @CaptureSpan()
   public async verifyDevice(deviceId: string): Promise<void> {
     await this.updateOneBy({

package/Server/Services/UserService.ts

@@ -133,6 +133,17 @@ export class Service extends DatabaseService<Model> {
     userId: ObjectID;
     projectId: ObjectID;
   }): Promise<string> {
+    /*
+     * Callers reach this through non-null assertions on nullable columns (an
+     * on-call timeline row for a coverage gap has no recipient, for example).
+     * Querying with an undefined id is not a harmless no-op — the id key is
+     * dropped from the WHERE clause, so the query degrades into "any user" and
+     * would name an arbitrary person. Fail closed instead.
+     */
+    if (!data.userId) {
+      return "";
+    }
+
     const user: Model | null = await this.findOneBy({
       query: {
         _id: data.userId,

package/Server/Services/UserSmsService.ts

@@ -7,7 +7,10 @@ import DatabaseService from "./DatabaseService";
 import ProjectCallSMSConfigService from "./ProjectCallSMSConfigService";
 import ProjectService from "./ProjectService";
 import SmsService from "./SmsService";
-import UserNotificationRuleService from "./UserNotificationRuleService";
+import UserNotificationRuleService, {
+  NotificationDeletionImpact,
+  NotificationMethodChannel,
+} from "./UserNotificationRuleService";
 import LIMIT_MAX from "../../Types/Database/LimitMax";
 import TwilioConfig from "../../Types/CallAndSMS/TwilioConfig";
 import BadDataException from "../../Types/Exception/BadDataException";
@@ -59,6 +62,28 @@ export class Service extends DatabaseService<Model> {
     };
   }
 
+  /**
+   * What this user would lose if this number were deleted. Ask BEFORE calling
+   * delete; nothing here refuses anything.
+   *
+   * The hook directly above deletes every UserNotificationRule that points at
+   * this number, and the foreign key is onDelete: "CASCADE" so the rows would
+   * go even if it did not. A phone number is the method people most often
+   * retire — a new handset, a new country — and it is also the one whose delete
+   * dialog gives no hint that an on-call configuration hangs off it.
+   */
+  @CaptureSpan()
+  public async getDeletionImpact(data: {
+    itemId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<NotificationDeletionImpact> {
+    return UserNotificationRuleService.getNotificationMethodDeletionImpact({
+      projectId: data.projectId,
+      methodType: NotificationMethodChannel.SMS,
+      methodId: data.itemId,
+    });
+  }
+
   @CaptureSpan()
   protected override async onBeforeCreate(
     createBy: CreateBy<Model>,

package/Server/Services/UserTelegramService.ts

@@ -4,7 +4,10 @@ import DeleteBy from "../Types/Database/DeleteBy";
 import { OnCreate, OnDelete } from "../Types/Database/Hooks";
 import DatabaseService from "./DatabaseService";
 import ProjectService from "./ProjectService";
-import UserNotificationRuleService from "./UserNotificationRuleService";
+import UserNotificationRuleService, {
+  NotificationDeletionImpact,
+  NotificationMethodChannel,
+} from "./UserNotificationRuleService";
 import LIMIT_MAX from "../../Types/Database/LimitMax";
 import BadDataException from "../../Types/Exception/BadDataException";
 import ObjectID from "../../Types/ObjectID";
@@ -55,6 +58,26 @@ export class Service extends DatabaseService<Model> {
     };
   }
 
+  /**
+   * What this user would lose if this Telegram account were deleted. Ask BEFORE
+   * calling delete; nothing here refuses anything.
+   *
+   * The hook directly above deletes every UserNotificationRule that points at
+   * this account, and the foreign key is onDelete: "CASCADE" so the rows would
+   * go even if it did not.
+   */
+  @CaptureSpan()
+  public async getDeletionImpact(data: {
+    itemId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<NotificationDeletionImpact> {
+    return UserNotificationRuleService.getNotificationMethodDeletionImpact({
+      projectId: data.projectId,
+      methodType: NotificationMethodChannel.Telegram,
+      methodId: data.itemId,
+    });
+  }
+
   @CaptureSpan()
   protected override async onBeforeCreate(
     createBy: CreateBy<Model>,

package/Server/Services/UserWebhookService.ts

@@ -3,9 +3,13 @@ import DeleteBy from "../Types/Database/DeleteBy";
 import UpdateBy from "../Types/Database/UpdateBy";
 import { OnCreate, OnDelete, OnUpdate } from "../Types/Database/Hooks";
 import DatabaseService from "./DatabaseService";
-import UserNotificationRuleService from "./UserNotificationRuleService";
+import UserNotificationRuleService, {
+  NotificationDeletionImpact,
+  NotificationMethodChannel,
+} from "./UserNotificationRuleService";
 import LIMIT_MAX from "../../Types/Database/LimitMax";
 import BadDataException from "../../Types/Exception/BadDataException";
+import ObjectID from "../../Types/ObjectID";
 import Model from "../../Models/DatabaseModels/UserWebhook";
 import URL from "../../Types/API/URL";
 import logger from "../Utils/Logger";
@@ -128,6 +132,29 @@ export class Service extends DatabaseService<Model> {
       carryForward: null,
     };
   }
+
+  /**
+   * What this user would lose if this webhook were deleted. Ask BEFORE calling
+   * delete; nothing here refuses anything.
+   *
+   * The hook directly above deletes every UserNotificationRule that points at
+   * this webhook, and the foreign key is onDelete: "CASCADE" so the rows would
+   * go even if it did not. A webhook has no verification concept at all, which
+   * makes it the one method that counts the moment it exists — and therefore
+   * the one whose deletion can take a responder from reachable to unreachable
+   * with nothing in between.
+   */
+  @CaptureSpan()
+  public async getDeletionImpact(data: {
+    itemId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<NotificationDeletionImpact> {
+    return UserNotificationRuleService.getNotificationMethodDeletionImpact({
+      projectId: data.projectId,
+      methodType: NotificationMethodChannel.Webhook,
+      methodId: data.itemId,
+    });
+  }
 }
 
 export default new Service();

package/Server/Services/UserWhatsAppService.ts

@@ -5,7 +5,10 @@ import { OnCreate, OnDelete } from "../Types/Database/Hooks";
 import logger, { LogAttributes } from "../Utils/Logger";
 import DatabaseService from "./DatabaseService";
 import ProjectService from "./ProjectService";
-import UserNotificationRuleService from "./UserNotificationRuleService";
+import UserNotificationRuleService, {
+  NotificationDeletionImpact,
+  NotificationMethodChannel,
+} from "./UserNotificationRuleService";
 import WhatsAppService from "./WhatsAppService";
 import LIMIT_MAX from "../../Types/Database/LimitMax";
 import BadDataException from "../../Types/Exception/BadDataException";
@@ -66,6 +69,26 @@ export class Service extends DatabaseService<Model> {
     };
   }
 
+  /**
+   * What this user would lose if this WhatsApp number were deleted. Ask BEFORE
+   * calling delete; nothing here refuses anything.
+   *
+   * The hook directly above deletes every UserNotificationRule that points at
+   * this number, and the foreign key is onDelete: "CASCADE" so the rows would
+   * go even if it did not.
+   */
+  @CaptureSpan()
+  public async getDeletionImpact(data: {
+    itemId: ObjectID;
+    projectId: ObjectID;
+  }): Promise<NotificationDeletionImpact> {
+    return UserNotificationRuleService.getNotificationMethodDeletionImpact({
+      projectId: data.projectId,
+      methodType: NotificationMethodChannel.WhatsApp,
+      methodId: data.itemId,
+    });
+  }
+
   @CaptureSpan()
   protected override async onBeforeCreate(
     createBy: CreateBy<Model>,

package/Server/Types/Database/Permissions/BasePermission.ts

@@ -4,6 +4,7 @@ import QueryUtil from "../QueryUtil";
 import Select from "../Select";
 import AccessControlPermission from "./AccessControlPermission";
 import OwnedScopePermission from "./OwnedScopePermission";
+import OwnerOnlyColumnPermission from "./OwnerOnlyColumnPermission";
 import PermissionUtil from "./PermissionsUtil";
 import PublicPermission from "./PublicPermission";
 import QueryPermission from "./QueryPermission";
@@ -175,8 +176,26 @@ export default class BasePermission {
         if (select) {
           // check query permission.
           SelectPermission.checkSelectPermission(modelType, select, props);
+
+          /*
+           * Both of the calls below are handed the query as it stands AFTER
+           * tenant and user scoping, which is the only moment it means
+           * anything. Before that scoping a plain member's query is still bare
+           * `{}` and would look unscoped; after serializeQuery (further down)
+           * the ownership predicate has been rewritten into a Raw operator and
+           * can no longer be compared to the caller's id. Here, and only here,
+           * the query says plainly which rows this request may touch.
+           */
+          OwnerOnlyColumnPermission.checkSelectPermission(
+            modelType,
+            query,
+            select,
+            props,
+          );
+
           QueryPermission.checkRelationQueryPermission(
             modelType,
+            query,
             select,
             props,
           );

package/Server/Types/Database/Permissions/CreatePermission.ts

@@ -1,8 +1,11 @@
 import DatabaseRequestType from "../../BaseDatabase/DatabaseRequestType";
 import ColumnPermissions from "./ColumnPermission";
 import TablePermission from "./TablePermission";
+import TenantPermission from "./TenantPermission";
 import BaseModel from "../../../../Models/DatabaseModels/DatabaseBaseModel/DatabaseBaseModel";
 import DatabaseCommonInteractionProps from "../../../../Types/BaseDatabase/DatabaseCommonInteractionProps";
+import NotAuthorizedException from "../../../../Types/Exception/NotAuthorizedException";
+import ObjectID from "../../../../Types/ObjectID";
 import CaptureSpan from "../../../Utils/Telemetry/CaptureSpan";
 
 export default class CreatePermission {
@@ -32,6 +35,167 @@ export default class CreatePermission {
       props,
       DatabaseRequestType.Create,
     );
+
+    CreatePermission.checkCreateOwnership(modelType, data, props);
+  }
+
+  /**
+   * Constrain the VALUE of a user-scoped model's ownership column, not merely
+   * whether the caller is allowed to write that column at all.
+   *
+   * Read, update and delete all convert Permission.CurrentUser into a row
+   * predicate: TenantPermission.addCurrentUserScopeToQuery rewrites the query to
+   * `userId = me` and rejects any operation that named somebody else. Create had
+   * no equivalent. The three checks above answer "may this caller write to this
+   * table" and "may this caller write to these COLUMNS" — neither receives the
+   * ownership value, and TablePermission.checkTableLevelPermissions is not even
+   * handed the data object. So @CurrentUserCanAccessRecordBy was effectively
+   * dead metadata on this path, and the carve-out is explicit in the sibling
+   * code: TenantPermission's misconfiguration guard reads
+   * `isAccessGrantedOnlyByCurrentUser && type !== DatabaseRequestType.Create`.
+   *
+   * The consequence was that a caller could write a row owned by somebody else
+   * on any model whose create list is CurrentUser-only — fourteen of them, all
+   * "my own X" resources: notification rules and every notification method
+   * behind them, sessions, TOTP and WebAuthn credentials. On the notification
+   * models that is not a bookkeeping error. A row's ownership column decides
+   * whose on-call pages select it, while the delivery address is read from the
+   * method relation the row points at, so a mismatched pair sends one person's
+   * pages to another person's address. Some services also seed further rows from
+   * whatever ownership value they are handed, which propagates the mistake
+   * without any further request.
+   *
+   * The check is permission-AWARE rather than a blanket stamp, and that
+   * distinction is load-bearing. Stamping `data[userColumn] = props.userId`
+   * unconditionally would make legitimate on-behalf-of creation impossible for
+   * an administrator who genuinely holds a role permission in the model's create
+   * list — so instead this mirrors exactly the condition the query-side scope
+   * uses. When CurrentUser is the ONLY thing letting the caller through, they
+   * may create rows for themselves and nobody else. When they hold a real role
+   * permission, this returns and that permission's own rules apply.
+   *
+   * props.isRoot short-circuits before this runs, so internal seeding (default
+   * notification rules, invitation acceptance, migrations) is unaffected.
+   */
+  private static checkCreateOwnership<TBaseModel extends BaseModel>(
+    modelType: { new (): TBaseModel },
+    data: TBaseModel,
+    props: DatabaseCommonInteractionProps,
+  ): void {
+    const model: BaseModel = new modelType();
+    const userColumn: string | null = model.getUserColumn();
+
+    if (!userColumn) {
+      // The model does not scope rows by user; there is no ownership to enforce.
+      return;
+    }
+
+    const isAccessGrantedOnlyByCurrentUser: boolean =
+      TenantPermission.isAccessGrantedOnlyByCurrentUser(
+        modelType,
+        props,
+        DatabaseRequestType.Create,
+      );
+
+    if (!isAccessGrantedOnlyByCurrentUser) {
+      /*
+       * The caller holds a role permission that appears in this model's create
+       * list, so they are not here purely as "some logged-in user". Whatever
+       * that permission is allowed to do is decided by the permission itself.
+       */
+      return;
+    }
+
+    /*
+     * CurrentUser is auto-granted to every authenticated caller, including API
+     * keys, which have no user identity. Such a grant can never be resolved to
+     * an owner, so reject it rather than writing an unowned row. This mirrors
+     * the equivalent guard on the query side.
+     */
+    if (!props.userId) {
+      throw new NotAuthorizedException(
+        `A user session is required to create ${model.singularName}.`,
+      );
+    }
+
+    /*
+     * The ownership column has TWO spellings and both write the same database
+     * column.
+     *
+     * A user-scoped model declares a scalar (`userId`) and a ManyToOne relation
+     * (`user`) whose @JoinColumn names that same scalar. Both are separately
+     * decorated, both are separately creatable, and TypeORM resolves either into
+     * the one join column. Checking only the scalar would therefore close
+     * nothing: a payload sending `user: { _id: <someone else> }` and no `userId`
+     * reaches this method with the scalar absent, gets the caller's own id
+     * stamped onto it, and then hands the persistence layer two disagreeing
+     * instructions about who owns the row.
+     *
+     * So the relation is validated identically and then CLEARED. Clearing rather
+     * than merely rejecting a mismatch removes the ambiguity entirely — after
+     * this method the scalar is the single source of ownership, and no
+     * TypeORM-version-dependent precedence rule between the two spellings can
+     * change who the row belongs to.
+     *
+     * The relation's property name is the scalar minus its `Id` suffix, which
+     * holds for every user-scoped model in the schema. A model that does not
+     * follow it simply has no relation to clear, and the scalar check below
+     * still applies.
+     */
+    const relationColumn: string = userColumn.endsWith("Id")
+      ? userColumn.slice(0, -2)
+      : "";
+
+    const suppliedOwnerRelation: unknown = relationColumn
+      ? data.getColumnValue(relationColumn)
+      : undefined;
+
+    if (
+      suppliedOwnerRelation !== undefined &&
+      suppliedOwnerRelation !== null &&
+      typeof suppliedOwnerRelation === "object"
+    ) {
+      const relationOwnerId: unknown = (
+        suppliedOwnerRelation as Record<string, unknown>
+      )["_id"];
+
+      if (
+        relationOwnerId !== undefined &&
+        relationOwnerId !== null &&
+        String(relationOwnerId) !== (props.userId as ObjectID).toString()
+      ) {
+        throw new NotAuthorizedException(
+          `You do not have permission to create another user's ${model.singularName}.`,
+        );
+      }
+
+      data.setColumnValue(relationColumn, undefined);
+    }
+
+    const suppliedOwner: unknown = data.getColumnValue(userColumn);
+
+    if (suppliedOwner === undefined || suppliedOwner === null) {
+      /*
+       * Omitting the column is the common case for a first-party client, which
+       * has no reason to send its own id back. Stamp it rather than leaving the
+       * row unowned — an unowned row is invisible to every scoped read, so it
+       * would be undeletable through the API that created it.
+       */
+      data.setColumnValue(userColumn, props.userId);
+
+      return;
+    }
+
+    const suppliedOwnerId: string =
+      suppliedOwner instanceof ObjectID
+        ? suppliedOwner.toString()
+        : String(suppliedOwner);
+
+    if (suppliedOwnerId !== (props.userId as ObjectID).toString()) {
+      throw new NotAuthorizedException(
+        `You do not have permission to create another user's ${model.singularName}.`,
+      );
+    }
   }
 
   @CaptureSpan()