@oneuptime/common 12.0.13 → 12.0.14

package/Server/Services/AnalyticsDatabaseService.ts

@@ -1542,6 +1542,159 @@ export default class AnalyticsDatabaseService<
     return { ...sort, _id: direction } as Sort<TBaseModel>;
   }
 
+  /**
+   * Bounds the rows an `ORDER BY ... , _id` find has to sort, without
+   * changing which rows it returns.
+   *
+   * ClickHouse can read in sorting-key order — and stop early — only when the
+   * ORDER BY lines up with the table's physical key. The `_id` tiebreaker
+   * appended by `toPaginationStableSort` is deliberately NOT a sorting-key
+   * column, so it denies that plan: the engine reads every row matching the
+   * WHERE, sorts the lot in memory, then discards all but one page. On the
+   * Logs viewer that turned a 100-row page into a full-window scan and tripped
+   * the 3 GiB `max_memory_usage` ceiling (Code 241, surfacing as
+   * "Server Error").
+   *
+   * Weakening the tiebreaker would reintroduce the skip/repeat paging bug it
+   * was added to fix, so bound the input instead. `min(k)` over the top
+   * `skip + limit` values of the leading sort key `k` is a rank statistic of
+   * k's MULTISET: it does not depend on which of several tied rows the inner
+   * LIMIT happened to keep. Every row that could reach position `skip + limit`
+   * satisfies `k >= min(k)`, and every row tied at the boundary value is
+   * admitted — so the page is exactly the page the unbounded query returns.
+   * That is what makes this a pure cost change: every gate below is a
+   * performance gate, and getting one wrong can only make a query slower,
+   * never lose or repeat a row.
+   *
+   * The inner pass reads one narrow key column in physical order and stops at
+   * `skip + limit` rows, so it costs far less than the wide outer read it
+   * saves.
+   *
+   * `min()` is nested over a subquery rather than taken as the N-th value via
+   * `ORDER BY k DESC LIMIT 1 OFFSET n - 1` on purpose: on a final page with
+   * fewer than `skip + limit` matching rows the latter returns no row, the
+   * scalar is NULL, `k >= NULL` is NULL, and the page comes back empty.
+   * `min()` over the available rows degrades to the smallest matching value.
+   */
+  private toSortKeyBoundaryFilter(
+    findBy: FindBy<TBaseModel>,
+    sort: Sort<TBaseModel>,
+    options: { hasGroupBy: boolean; databaseName: string },
+  ): Statement | null {
+    /*
+     * Under GROUP BY the predicate would restrict the aggregation INPUT
+     * rather than the page, so it would change results. Mirrors the
+     * tiebreaker's own exemption, leaving grouped finds byte-identical.
+     */
+    if (options.hasGroupBy) {
+      return null;
+    }
+
+    /*
+     * Without an `_id` column there is no off-key tiebreaker — the six
+     * `includeBaseColumns: false` aggregate targets — so the ORDER BY is
+     * already key-aligned and the bound would be pure overhead. Same
+     * condition toPaginationStableSort bails on.
+     */
+    const hasIdColumn: boolean = this.model.tableColumns.some(
+      (column: AnalyticsTableColumn): boolean => {
+        return column.key === "_id";
+      },
+    );
+
+    if (!hasIdColumn) {
+      return null;
+    }
+
+    const leadingSortKey: string | undefined = Object.keys(sort || {})[0];
+
+    if (!leadingSortKey) {
+      return null;
+    }
+
+    /*
+     * Only a column in the physical sorting key can be read in order, so
+     * only there can the off-key `_id` term have cost anything. Off-key
+     * leads (e.g. Log by `severityText`) already plan a bounded top-N and
+     * an extra pass would be pure waste.
+     */
+    if (!this.model.sortKeys.includes(leadingSortKey)) {
+      return null;
+    }
+
+    /*
+     * A non-required column is `Nullable(...)` in the DDL, and `k >= NULL`
+     * is NULL — the predicate would DROP those rows rather than just
+     * narrowing the scan. Fail safe to today's behavior.
+     */
+    const leadingSortColumn: AnalyticsTableColumn | null =
+      this.model.getTableColumn(leadingSortKey);
+
+    if (!leadingSortColumn || !leadingSortColumn.required) {
+      return null;
+    }
+
+    /*
+     * `findOneById` funnels a point lookup through `findOneBy` carrying the
+     * model's default sort. At most one row can match, so bounding it would
+     * double a query that has no ordering problem to begin with.
+     */
+    if ((findBy.query as Record<string, unknown> | undefined)?.["_id"]) {
+      return null;
+    }
+
+    /*
+     * The predicate is valid only BECAUSE of LIMIT/OFFSET: it admits the
+     * rows that can reach position `skip + limit` and no more. Guards the
+     * `new PositiveNumber(undefined)` -> NaN path that exists upstream.
+     */
+    const limit: number = Number(findBy.limit);
+    const skip: number = Number(findBy.skip);
+
+    if (!Number.isFinite(limit) || !Number.isFinite(skip)) {
+      return null;
+    }
+
+    const boundaryRowCount: number = skip + limit;
+
+    if (boundaryRowCount <= 0) {
+      return null;
+    }
+
+    const isDescending: boolean =
+      (sort as Record<string, SortOrder | undefined>)[leadingSortKey] !==
+      SortOrder.Ascending;
+
+    /*
+     * The bound must be computed over the same row set the outer query
+     * filters on, so the WHERE is regenerated rather than shared: appending
+     * one Statement into two places would bind its parameters twice.
+     */
+    const boundaryWhereStatement: Statement =
+      this.statementGenerator.toWhereStatement(findBy.query);
+
+    const boundaryStatement: Statement = SQL` AND ${leadingSortKey} `;
+
+    boundaryStatement.append(isDescending ? SQL`>=` : SQL`<=`);
+    boundaryStatement.append(
+      isDescending
+        ? SQL` (SELECT min(${leadingSortKey}) FROM (SELECT ${leadingSortKey} FROM ${options.databaseName}.${this.model.tableName} WHERE TRUE `
+        : SQL` (SELECT max(${leadingSortKey}) FROM (SELECT ${leadingSortKey} FROM ${options.databaseName}.${this.model.tableName} WHERE TRUE `,
+    );
+    boundaryStatement.append(boundaryWhereStatement);
+    boundaryStatement.append(this.getRetentionReadFilter());
+    boundaryStatement.append(SQL` ORDER BY ${leadingSortKey} `);
+    boundaryStatement.append(isDescending ? SQL`DESC` : SQL`ASC`);
+    boundaryStatement.append(
+      SQL` LIMIT ${{
+        value: boundaryRowCount,
+        type: TableColumnType.Number,
+      }}))`,
+    );
+
+    return boundaryStatement;
+  }
+
   public toFindStatement(findBy: FindBy<TBaseModel>): {
     statement: Statement;
     columns: Array<string>;
@@ -1577,6 +1730,18 @@ export default class AnalyticsDatabaseService<
       }),
     );
 
+    /*
+     * Keeps the `_id` tiebreaker affordable. Result-preserving by
+     * construction, so it is appended to the WHERE without touching the
+     * ORDER BY above. Null whenever the bound cannot help or cannot be
+     * proven safe.
+     */
+    const sortKeyBoundaryStatement: Statement | null =
+      this.toSortKeyBoundaryFilter(findBy, findBy.sort!, {
+        hasGroupBy: Boolean(groupByStatement),
+        databaseName: databaseName,
+      });
+
     const statement: Statement = SQL``;
 
     statement.append(SQL`SELECT `.append(select.statement));
@@ -1586,6 +1751,10 @@ export default class AnalyticsDatabaseService<
       .append(whereStatement)
       .append(this.getRetentionReadFilter());
 
+    if (sortKeyBoundaryStatement) {
+      statement.append(sortKeyBoundaryStatement);
+    }
+
     if (groupByStatement) {
       statement.append(SQL` GROUP BY `).append(groupByStatement);
     }

package/Server/Services/DatabaseService.ts

@@ -2886,6 +2886,107 @@ class DatabaseService<TBaseModel extends BaseModel> extends BaseService {
     await repository.manager.query(sql, params);
   }
 
+  /*
+   * Add one to a numeric column and return what it became, in a SINGLE
+   * statement.
+   *
+   * This exists for counters that GATE something, where the read and the
+   * write cannot be allowed to come apart. The motivating case is the failed
+   * attempt counter on a notification-channel verification code: read the
+   * count, decide, then write it back, and N requests racing each other all
+   * read the same pre-increment value and all decide they are under the
+   * limit — which is precisely the shape an attacker running a brute-force
+   * loop produces. `atomicAddToColumnsByIdWithoutHooks` closes the
+   * lost-update half of that but cannot answer "and what is it now?", and
+   * `getRepository().increment()` cannot either.
+   *
+   * RETURNING makes the increment and the observation the same operation, so
+   * every concurrent caller gets a distinct value and the k-th attempt is
+   * refused no matter how the requests interleave.
+   *
+   * COALESCE so a NULL counter starts from zero rather than staying NULL.
+   *
+   * The column and table identifiers come from entity metadata, never from
+   * the caller, and the id is bound as a parameter. Hooks, the `version`
+   * bump and access control are all skipped: use ONLY for trusted internal
+   * counter writes.
+   */
+  @CaptureSpan()
+  public async atomicIncrementColumnValueByOneAndGetValue(data: {
+    id: ObjectID;
+    columnName: keyof TBaseModel;
+  }): Promise<number> {
+    if (!data.id) {
+      throw new BadDataException("id is required");
+    }
+
+    const repository: Repository<TBaseModel> = this.getRepository();
+    const metadata: EntityMetadata = repository.metadata;
+
+    const column: ColumnMetadata | undefined =
+      metadata.findColumnWithPropertyName(data.columnName as string);
+
+    if (!column) {
+      throw new BadDataException(
+        `atomicIncrementColumnValueByOneAndGetValue: unknown column "${String(
+          data.columnName,
+        )}" on "${metadata.tableName}"`,
+      );
+    }
+
+    const primaryColumnName: string =
+      metadata.primaryColumns[0]?.databaseName || "_id";
+
+    const quoted: string = `"${column.databaseName}"`;
+
+    const sql: string = `UPDATE "${metadata.tableName}" SET ${quoted} = COALESCE(${quoted}, 0) + 1 WHERE "${primaryColumnName}" = $1 RETURNING ${quoted}`;
+
+    const result: unknown = await repository.manager.query(sql, [
+      data.id.toString(),
+    ]);
+
+    /*
+     * TypeORM's Postgres driver returns `[rows, affectedCount]` for an UPDATE
+     * and a bare row array for everything else, so both shapes are unwrapped
+     * rather than one being assumed.
+     */
+    const rows: Array<unknown> = Array.isArray(result)
+      ? Array.isArray(result[0])
+        ? (result[0] as Array<unknown>)
+        : (result as Array<unknown>)
+      : [];
+
+    const row: unknown = rows[0];
+
+    if (!row || typeof row !== "object" || Array.isArray(row)) {
+      /*
+       * Nothing came back, so the row does not exist — deleted underneath us,
+       * or never there. Callers gate on the returned count, so this must be an
+       * error and not a zero, which would read as a fresh allowance.
+       */
+      throw new BadDataException(
+        `Item with ID ${data.id.toString()} not found`,
+      );
+    }
+
+    const value: unknown = (row as Record<string, unknown>)[
+      column.databaseName
+    ];
+
+    const parsed: number =
+      typeof value === "number" ? value : parseInt(String(value), 10);
+
+    if (!Number.isFinite(parsed)) {
+      throw new BadDataException(
+        `atomicIncrementColumnValueByOneAndGetValue: "${String(
+          data.columnName,
+        )}" did not return a number`,
+      );
+    }
+
+    return parsed;
+  }
+
   @CaptureSpan()
   protected async atomicIncrementColumnValueByOne(data: {
     id: ObjectID;

package/Server/Services/LogAggregationService.ts

@@ -282,6 +282,7 @@ export class LogAggregationService {
       getQuerySettings({
         maxExecutionTimeInSeconds: 45,
         timeoutOverflowMode: "break",
+        boundScanMemory: true,
         additionalSettings: { optimize_use_projections: 1 },
       }),
     );
@@ -392,6 +393,7 @@ export class LogAggregationService {
       getQuerySettings({
         maxExecutionTimeInSeconds: 45,
         timeoutOverflowMode: "break",
+        boundScanMemory: true,
       }),
     );
 
@@ -634,6 +636,7 @@ export class LogAggregationService {
       getQuerySettings({
         maxExecutionTimeInSeconds: 45,
         timeoutOverflowMode: "break",
+        boundScanMemory: true,
       }),
     );
 
@@ -714,6 +717,7 @@ export class LogAggregationService {
       getQuerySettings({
         maxExecutionTimeInSeconds: 45,
         timeoutOverflowMode: "break",
+        boundScanMemory: true,
       }),
     );
 
@@ -783,6 +787,7 @@ export class LogAggregationService {
       getQuerySettings({
         maxExecutionTimeInSeconds: 45,
         timeoutOverflowMode: "break",
+        boundScanMemory: true,
       }),
     );
 

package/Server/Services/PushNotificationService.ts

@@ -26,6 +26,7 @@ import UserPush from "../../Models/DatabaseModels/UserPush";
 import PushNotificationLog from "../../Models/DatabaseModels/PushNotificationLog";
 import PushNotificationLogService from "./PushNotificationLogService";
 import PushStatus from "../../Types/PushNotification/PushStatus";
+import AndroidNotificationChannel from "../../Types/PushNotification/AndroidNotificationChannel";
 
 /*
  * The push services the browsers actually use. A Web Push subscription is a
@@ -67,6 +68,43 @@ export interface PushNotificationOptions {
   teamId?: ObjectID | undefined;
 }
 
+/*
+ * What Expo needs to be told for a notification to ring through a silenced
+ * handset. The two platforms disagree about where the answer lives, so this is
+ * computed once and reused by both the direct-SDK and relay send paths.
+ *
+ * iOS reads the payload: a `sound` object with `critical: true` plus
+ * `interruptionLevel: "critical"` is what makes APNs ignore the ringer switch
+ * and Focus, and it is refused unless the app carries Apple's critical-alert
+ * entitlement.
+ *
+ * Android ignores all of that and reads the CHANNEL. Sound, importance and Do
+ * Not Disturb bypass are baked into the channel when the app creates it and
+ * cannot be raised by a payload, so the only lever the server has is which
+ * channel id it names.
+ */
+export type ExpoPushSound =
+  | string
+  | null
+  | {
+      critical?: boolean;
+      name?: string | null;
+      volume?: number;
+    };
+
+export type ExpoInterruptionLevel =
+  | "active"
+  | "critical"
+  | "passive"
+  | "time-sensitive";
+
+export interface ExpoDeliveryOptions {
+  channelId: string;
+  sound: ExpoPushSound;
+  priority: "high";
+  interruptionLevel?: ExpoInterruptionLevel;
+}
+
 export default class PushNotificationService {
   public static isWebPushInitialized = false;
   private static expoClient: Expo = new Expo(
@@ -408,6 +446,57 @@ export default class PushNotificationService {
     }
   }
 
+  /*
+   * Volume is pinned rather than exposed as a setting. A critical alert exists
+   * to wake somebody, and a responder who has already opted this device in and
+   * granted the OS permission has not asked to be woken quietly.
+   */
+  public static readonly CRITICAL_ALERT_VOLUME: number = 1;
+
+  public static getExpoDeliveryOptions(
+    message: PushNotificationMessage,
+    deviceType: PushDeviceType,
+  ): ExpoDeliveryOptions {
+    const isAndroid: boolean = deviceType === PushDeviceType.Android;
+    const isCritical: boolean = Boolean(message.isCriticalAlert);
+
+    /*
+     * iOS has no channels, so "default" here is the payload's own sound rather
+     * than a channel id. Android without the critical flag stays on
+     * oncall_high, which is what every push has used until now.
+     */
+    const channelId: string = isAndroid
+      ? isCritical
+        ? AndroidNotificationChannel.Critical
+        : AndroidNotificationChannel.High
+      : "default";
+
+    if (!isCritical) {
+      return {
+        channelId: channelId,
+        sound: "default",
+        priority: "high",
+      };
+    }
+
+    return {
+      channelId: channelId,
+      /*
+       * Sent to Android too, and harmlessly ignored there. Expo forwards it to
+       * APNs where it is the whole mechanism, and to FCM where the channel has
+       * already decided the sound; keeping one shape avoids a per-platform
+       * branch that could silently drop the iOS half.
+       */
+      sound: {
+        critical: true,
+        name: "default",
+        volume: PushNotificationService.CRITICAL_ALERT_VOLUME,
+      },
+      priority: "high",
+      interruptionLevel: "critical",
+    };
+  }
+
   private static async sendExpoPushNotification(
     expoPushToken: string,
     message: PushNotificationMessage,
@@ -430,8 +519,10 @@ export default class PushNotificationService {
       dataPayload["url"] = message.url || message.clickAction || "";
     }
 
-    const channelId: string =
-      deviceType === PushDeviceType.Android ? "oncall_high" : "default";
+    const delivery: ExpoDeliveryOptions = this.getExpoDeliveryOptions(
+      message,
+      deviceType,
+    );
 
     // If EXPO_ACCESS_TOKEN is not set, relay through the push notification gateway
     if (!ExpoAccessToken) {
@@ -439,7 +530,7 @@ export default class PushNotificationService {
         expoPushToken,
         message,
         dataPayload,
-        channelId,
+        delivery,
         deviceType,
       );
       return;
@@ -452,9 +543,12 @@ export default class PushNotificationService {
         title: message.title,
         body: message.body,
         data: dataPayload,
-        sound: "default",
-        priority: "high",
-        channelId: channelId,
+        sound: delivery.sound,
+        priority: delivery.priority,
+        channelId: delivery.channelId,
+        ...(delivery.interruptionLevel
+          ? { interruptionLevel: delivery.interruptionLevel }
+          : {}),
       };
 
       const tickets: ExpoPushTicket[] =
@@ -500,7 +594,7 @@ export default class PushNotificationService {
     expoPushToken: string,
     message: PushNotificationMessage,
     dataPayload: { [key: string]: string },
-    channelId: string,
+    delivery: ExpoDeliveryOptions,
     deviceType: PushDeviceType,
   ): Promise<void> {
     logger.info(
@@ -516,9 +610,19 @@ export default class PushNotificationService {
             title: message.title || "",
             body: message.body || "",
             data: dataPayload,
-            sound: "default",
-            priority: "high",
-            channelId: channelId,
+            /*
+             * The relay re-sends exactly what it is given, so a critical page
+             * that loses its sound object here arrives on the responder's
+             * phone as an ordinary silent notification. That is the failure
+             * this feature exists to prevent, so the whole delivery shape
+             * crosses the wire rather than the channel id alone.
+             */
+            sound: delivery.sound,
+            priority: delivery.priority,
+            channelId: delivery.channelId,
+            ...(delivery.interruptionLevel
+              ? { interruptionLevel: delivery.interruptionLevel }
+              : {}),
           },
         });
 
@@ -552,9 +656,10 @@ export default class PushNotificationService {
     title?: string;
     body?: string;
     data?: { [key: string]: string };
-    sound?: string;
+    sound?: ExpoPushSound;
     priority?: string;
     channelId?: string;
+    interruptionLevel?: ExpoInterruptionLevel;
   }): Promise<void> {
     if (!ExpoAccessToken) {
       throw new Error(
@@ -562,14 +667,24 @@ export default class PushNotificationService {
       );
     }
 
+    /*
+     * `sound: null` is a caller asking for a silent notification and has to
+     * survive, so the fallback tests for undefined rather than falsiness.
+     */
+    const sound: ExpoPushSound =
+      data.sound === undefined ? "default" : data.sound;
+
     const expoPushMessage: ExpoPushMessage = {
       to: data.to,
       title: data.title || "",
       body: data.body || "",
       data: data.data || {},
-      sound: (data.sound as "default" | null) || "default",
+      sound: sound,
       priority: (data.priority as "default" | "normal" | "high") || "high",
       channelId: data.channelId || "default",
+      ...(data.interruptionLevel
+        ? { interruptionLevel: data.interruptionLevel }
+        : {}),
     };
 
     const tickets: ExpoPushTicket[] =

package/Server/Services/TeamMemberService.ts

@@ -10,6 +10,7 @@ import UpdateBy from "../Types/Database/UpdateBy";
 import Errors from "../Utils/Errors";
 import logger, { LogAttributes } from "../Utils/Logger";
 import ProductAnalytics from "../Utils/ProductAnalytics";
+import UserRegistrationToken from "../Utils/UserRegistrationToken";
 import AccessTokenService from "./AccessTokenService";
 import BillingService from "./BillingService";
 import DatabaseService from "./DatabaseService";
@@ -166,8 +167,23 @@ export class TeamMemberService extends DatabaseService<TeamMember> {
         ? (createBy.miscDataProps["name"] as string).trim()
         : undefined;
 
-      let user: User | null = await UserService.findByEmail(email, {
-        isRoot: true,
+      /*
+       * `password` comes back too, because whether this person has finished
+       * registering decides both which link the invitation carries and whether
+       * that link needs a registration token. UserService.findByEmail selects
+       * only the id, so it cannot answer that.
+       */
+      let user: User | null = await UserService.findOneBy({
+        query: {
+          email: email,
+        },
+        select: {
+          _id: true,
+          password: true,
+        },
+        props: {
+          isRoot: true,
+        },
       });
 
       let isNewUser: boolean = false;
@@ -228,6 +244,39 @@ export class TeamMemberService extends DatabaseService<TeamMember> {
         const host: Hostname = await DatabaseConfig.getHost();
         const httpProtocol: Protocol = await DatabaseConfig.getHttpProtocol();
 
+        /*
+         * "Still has to register", not "we just created the row". Someone
+         * invited to a second project before they ever signed up already has a
+         * user row and still has no password, and used to be sent the sign-in
+         * link — which they could not use, having no password to sign in with.
+         */
+        const needsRegistration: boolean = isNewUser || !user.password;
+
+        /*
+         * The token is what lets the recipient claim this account, so it exists
+         * only on the link inside this email and only for someone who has not
+         * registered yet. An already-registered invitee gets the plain link;
+         * they sign in instead, and minting a claim token for an account that
+         * cannot be claimed would just be a spare key lying around.
+         */
+        const registerLink: string = needsRegistration
+          ? (
+              await UserRegistrationToken.generateRegistrationLink({
+                userId: user.id!,
+                email: email,
+              })
+            ).toString()
+          : URL.fromString(
+              new URL(
+                httpProtocol,
+                host,
+                new Route(AccountsRoute.toString()),
+              ).toString(),
+            )
+              .addRoute("/register")
+              .addQueryParam("email", email.toString(), true)
+              .toString();
+
         MailService.sendMail(
           {
             toEmail: email,
@@ -240,17 +289,8 @@ export class TeamMemberService extends DatabaseService<TeamMember> {
                   new Route(AccountsRoute.toString()),
                 ).toString(),
               ).toString(),
-              registerLink: URL.fromString(
-                new URL(
-                  httpProtocol,
-                  host,
-                  new Route(AccountsRoute.toString()),
-                ).toString(),
-              )
-                .addRoute("/register")
-                .addQueryParam("email", email.toString(), true)
-                .toString(),
-              isNewUser: isNewUser.toString(),
+              registerLink: registerLink,
+              isNewUser: needsRegistration.toString(),
               /*
                * An auto-accepted member has nothing left to accept, so the
                * template drops the "sign in to accept your invitation" framing