@solidxai/core 0.1.13-beta.8 → 0.1.13

package/src/services/refresh-token-ids-storage.service.ts

@@ -1,133 +1,272 @@
 import { CACHE_MANAGER } from '@nestjs/cache-manager';
 import { Inject, Injectable, forwardRef } from '@nestjs/common';
 import { Cache } from 'cache-manager';
+import { randomUUID } from 'crypto';
+import type { SolidCoreSetting } from 'src/services/settings/default-settings-provider.service';
 import { AuthenticationService } from './authentication.service';
+import { SettingService } from './setting.service';
 
 // TODO: Ideally this should be in a separate file - putting this here for brevity
 export class InvalidatedRefreshTokenError extends Error { }
 
+// How long a rotated-out refresh token stays acceptable. This window is the
+// point of keeping a previous token at all: concurrent requests from one user
+// must not break each other. core-ui's single-flight guard is module-level and
+// therefore per tab, so two tabs crossing the refresh threshold together will
+// both present the same token - the second one is served from here.
+const PREVIOUS_TOKEN_GRACE_MS = 60 * 1000;
+
+// The cache entry must outlive the JWT it holds. If it expired first, refresh
+// would fail with ACCESS_DENIED (InvalidatedRefreshTokenError) rather than the
+// SESSION_EXPIRED that the token's own `exp` produces - the same event
+// reported two different ways.
+const STATE_TTL_BUFFER_SECONDS = 60;
+
 type RefreshTokenState = {
     currentRefreshToken: string;
     previousRefreshToken: string;
+    // Absolute epoch-ms deadline after which previousRefreshToken is refused.
+    // Stored rather than scheduled: an in-process timer is lost when the pod
+    // restarts, which used to leave the rotated-out token valid until the next
+    // rotation instead of for one minute. Optional because entries written
+    // before this field existed will not carry it.
+    previousValidUntil?: number;
+};
+
+/**
+ * The bucket-identifying claims carried on a refresh token. Absent on tokens
+ * issued before per-device sessions existed, and on tokens issued while
+ * preventConcurrentLogins is on - which is exactly how the read path tells the
+ * two schemes apart without consulting any setting.
+ */
+export type RefreshTokenClaims = {
+    deviceKey?: string;
+    epoch?: number;
+};
+
+export type RotatedRefreshToken = {
+    refreshToken: string;
+    // The bucket the rotated token now lives in. Differs from the incoming
+    // deviceKey only when a pre-migration token was just moved into one.
+    deviceKey?: string;
 };
 
 @Injectable()
-// export class RefreshTokenIdsStorageService implements OnApplicationBootstrap, OnApplicationShutdown {
 export class RefreshTokenIdsStorageService {
-    // private redisClient: Redis;
-    // onApplicationBootstrap() {
-    //     // TODO: Ideally, we should move this to the dedicated "RedisModule" instead of initiating the connection here.
-    //     this.redisClient = new Redis({
-    //         // TODO: According to best practices, we should use the environment variables here instead.
-    //         host: 'localhost',
-    //         port: 6379,
-    //     });
-    // }
-    // onApplicationShutdown(signal?: string) {
-    //     return this.redisClient.quit();
-    // }
-
     constructor(
         @Inject(CACHE_MANAGER) private cacheManager: Cache,
         @Inject(forwardRef(() => AuthenticationService))
-        private readonly authenticationService: AuthenticationService
+        private readonly authenticationService: AuthenticationService,
+        private readonly settingService: SettingService,
     ) { }
 
-    async insert(userId: number, refreshToken: string, previousRefreshToken?: string): Promise<void> {
+    /**
+     * The inverse of the `preventConcurrentLogins` setting, and the only place
+     * it is interpreted.
+     *
+     * That setting already promises, when off, that sessions may coexist;
+     * splitting the refresh-token keyspace per device is what finally delivers
+     * it. When it is on, its stated purpose is a single live session, so
+     * per-device keys would be meaningless and the original single slot is kept.
+     *
+     * This governs the WRITE path only. Reads always branch on the token's own
+     * claim, so toggling the setting never invalidates a live session.
+     */
+    areConcurrentLoginsAllowed(): boolean {
+        return !this.settingService.getConfigValue<SolidCoreSetting>("preventConcurrentLogins");
+    }
+
+    async insert(
+        userId: number,
+        refreshToken: string,
+        previousRefreshToken?: string,
+        deviceKey?: string,
+    ): Promise<void> {
         const refreshTokenState: RefreshTokenState = {
             currentRefreshToken: refreshToken,
             previousRefreshToken: previousRefreshToken ?? "",
+            ...(previousRefreshToken
+                ? { previousValidUntil: Date.now() + PREVIOUS_TOKEN_GRACE_MS }
+                : {}),
         };
-        await this.cacheManager.set(this.getKey(userId), refreshTokenState);
+        await this.cacheManager.set(
+            this.getKey(userId, deviceKey),
+            refreshTokenState,
+            this.getStateTtlMs(),
+        );
     }
 
-    async validate(userId: number, refreshToken: string): Promise<boolean> {
-        // TODO: Assume you get this shape out of the cache {"currentRefreshToken": "", "previousRefreshToken": ""}
-        // Then you will compare against the currentRefreshToken.
-        const storedId = await this.cacheManager.get(this.getKey(userId));
-        if (storedId !== refreshToken) {
-            throw new InvalidatedRefreshTokenError();
-        }
-        return storedId === refreshToken;
+    async invalidate(userId: number, deviceKey?: string): Promise<void> {
+        await this.cacheManager.del(this.getKey(userId, deviceKey));
     }
 
-    async invalidate(userId: number): Promise<void> {
+    /**
+     * Bulk invalidation - "log out everywhere", and the right hook for password
+     * change or forced deactivation.
+     *
+     * Per-device buckets cannot be enumerated through cache-manager, so this
+     * bumps a per-user epoch that every per-device token carries as a claim.
+     * One write invalidates every outstanding token without a scan and without
+     * the read-modify-write race an index of device keys would have.
+     */
+    async invalidateAll(userId: number): Promise<void> {
+        const currentEpoch = (await this.getEpoch(userId)) ?? 0;
+        await this.cacheManager.set(
+            this.getEpochKey(userId),
+            currentEpoch + 1,
+            // Outlives every bucket that could hold a pre-bump token: those were
+            // written earlier, so they expire no later than this key does.
+            this.getStateTtlMs(),
+        );
+        // Single-slot mode and pre-migration entries live under the bare key,
+        // which carries no epoch claim - delete it directly.
         await this.cacheManager.del(this.getKey(userId));
     }
 
-    async validateAndRotate(user: any, refreshToken: string): Promise<string> {
-        let valid = false;
-
-        // TODO: Assume you get this shape out of the cache {"currentRefreshToken": "", "previousRefreshToken": ""}
-        // Then you will compare against the currentRefreshToken.
-        const refreshTokenState = await this.cacheManager.get(this.getKey(user.id)) as RefreshTokenState | undefined;
-
-        // Use the authentication service to generate a new refresh token, set it in the currentRefreshToken in scenario 1 and return.
-
-        // if UI.refresh_token is matching with Cache.currentRefreshToken
-        //   then invalidate (updated cache state, no need to delete anything), then generate new token and return.
-        //   also set a setTimeout to run after X minutes, this will simply update the RefreshTokenCacheState to this object {"currentRefreshToken": "R2","justInvalidatedRefreshToken": ""}
-        // valid=true
-
-        //   - if UI.refresh_token is matching Cache.justInvalidatedRefreshToken        
-        //       then use the Cache.currentRefreshToken, generate new access token and return.
-        //       We do not modify the cache state at all.
-        // valid=true
-
-        let newRefreshToken: string | undefined;
-        if (
-            refreshTokenState &&
-            typeof refreshTokenState === 'object' &&
-            'currentRefreshToken' in refreshTokenState &&
-            'previousRefreshToken' in refreshTokenState
-        ) {
-            if (refreshTokenState.currentRefreshToken === refreshToken) {
-                // Scenario 1: Token matches currentRefreshToken
-                valid = true;
-                // Rotate tokens: move current to previous, set new current (simulate generation)
-                newRefreshToken = await this.authenticationService.generateRefreshToken(user, refreshTokenState.currentRefreshToken); // Replace with real token generation logic
-
-
-                //   updated cache state
-                // await this.cacheManager.set(this.getKey(user.id), {
-                //     currentRefreshToken: newRefreshToken,
-                //     previousRefreshToken: refreshTokenState.currentRefreshToken,
-                // });
-
-                // Optionally, set a timeout to clear previousRefreshToken after X minutes
-                setTimeout(async () => {
-                    const state = (await this.cacheManager.get(this.getKey(user.id))) as any;
-                    if (state && state.currentRefreshToken === newRefreshToken) {
-                        await this.cacheManager.set(this.getKey(user.id), {
-                            currentRefreshToken: newRefreshToken,
-                            previousRefreshToken: "",
-                        });
-                    }
-                }, 1 * 60 * 1000); // 5 minutes
-            } else if (refreshTokenState.previousRefreshToken === refreshToken) {
-                // Scenario 2: Token matches previousRefreshToken
-                valid = true;
-                // Do not modify cache
-                // Generate new refresh token based on currentRefreshToken
-                const existingRefreshTokenState = (await this.cacheManager.get(this.getKey(user.id))) as RefreshTokenState | undefined;
-                newRefreshToken = existingRefreshTokenState?.currentRefreshToken;
+    async getEpoch(userId: number): Promise<number | undefined> {
+        return (await this.cacheManager.get<number>(this.getEpochKey(userId))) ?? undefined;
+    }
+
+    async validateAndRotate(
+        user: any,
+        refreshToken: string,
+        claims: RefreshTokenClaims = {},
+    ): Promise<RotatedRefreshToken> {
+        const { deviceKey, epoch } = claims;
+
+        // The read key comes from the token's own claim, never from a setting.
+        // A token issued under either scheme therefore stays valid when
+        // preventConcurrentLogins is toggled - in both directions - and a
+        // pre-migration token still finds the bare key it was written to.
+        const refreshTokenState = await this.cacheManager.get(
+            this.getKey(user.id, deviceKey),
+        ) as RefreshTokenState | undefined;
+
+        if (!this.isRefreshTokenState(refreshTokenState)) {
+            throw new InvalidatedRefreshTokenError();
+        }
+
+        if (deviceKey && !(await this.isEpochCurrent(user.id, epoch))) {
+            throw new InvalidatedRefreshTokenError();
+        }
+
+        // Scenario 1: the live token. Rotate it. generateRefreshToken calls
+        // insert(), which writes the new state and stamps the grace deadline
+        // onto the token being rotated out.
+        if (refreshTokenState.currentRefreshToken === refreshToken) {
+            const nextDeviceKey = this.resolveNextDeviceKey(deviceKey);
+            const rotated = await this.authenticationService.generateRefreshToken(
+                user,
+                refreshToken,
+                nextDeviceKey,
+            );
+
+            if (nextDeviceKey !== deviceKey) {
+                // The session changed buckets - either migrating out of the
+                // pre-deploy single slot, or collapsing back into it because
+                // preventConcurrentLogins was switched on. The new state is
+                // already written; drop the key it came from so nothing is
+                // left behind.
+                await this.cacheManager.del(this.getKey(user.id, deviceKey));
+            }
+
+            return { refreshToken: rotated, deviceKey: nextDeviceKey };
+        }
+
+        // Scenario 2: the token just rotated out. This is the concurrent-request
+        // case the previous slot exists for - a second in-flight request that
+        // was issued the old token before the first one rotated it. Hand back
+        // the live token so it succeeds, provided the grace window is still open.
+        if (refreshTokenState.previousRefreshToken && refreshTokenState.previousRefreshToken === refreshToken) {
+            if (!this.isWithinGraceWindow(refreshTokenState)) {
+                throw new InvalidatedRefreshTokenError();
             }
+            return { refreshToken: refreshTokenState.currentRefreshToken, deviceKey };
         }
 
+        throw new InvalidatedRefreshTokenError();
+    }
 
-        if (!valid) {
-            throw new InvalidatedRefreshTokenError();
+    getCurrentRefreshTokenState(
+        userId: number,
+        deviceKey?: string,
+    ): Promise<RefreshTokenState | undefined> {
+        return this.cacheManager.get(this.getKey(userId, deviceKey));
+    }
+
+    private getKey(userId: number, deviceKey?: string): string {
+        return deviceKey ? `user-${userId}-${deviceKey}` : `user-${userId}`;
+    }
+
+    // Deliberately not `user-${userId}-epoch`, which a device key of the
+    // literal string "epoch" would collide with.
+    private getEpochKey(userId: number): string {
+        return `user-epoch-${userId}`;
+    }
+
+    /**
+     * Which bucket a rotated token should land in. The setting is consulted
+     * first so that turning preventConcurrentLogins ON collapses existing
+     * per-device sessions back into the single slot on their next refresh -
+     * where normal last-login-wins applies, which is what that setting means.
+     * Leaving them in their own buckets would keep concurrent sessions alive
+     * while the setting claimed to forbid them.
+     */
+    private resolveNextDeviceKey(deviceKey?: string): string | undefined {
+        if (!this.areConcurrentLoginsAllowed()) {
+            return undefined;
         }
+        return deviceKey ?? randomUUID();
+    }
 
-        // TODO: return the refresh token either currentRefreshToken
-        return newRefreshToken; // Fallback to the provided tokenId if no new token was generated
+    private async isEpochCurrent(userId: number, epoch?: number): Promise<boolean> {
+        const storedEpoch = await this.getEpoch(userId);
+        // Nothing has ever been bulk-invalidated for this user - or the cache
+        // was flushed, in which case every bucket is gone and the token is
+        // already dead by the read above. Either way, accept.
+        if (storedEpoch === undefined) {
+            return true;
+        }
+        return epoch === storedEpoch;
+    }
+
+    // cache-manager v5 expects milliseconds; refreshTokenTtl is configured in
+    // seconds. Without an explicit TTL these entries never expire - neither
+    // cache path supplies a default - and the keyspace grows without bound.
+    private getStateTtlMs(): number {
+        const refreshTokenTtlSeconds = Number(
+            this.settingService.getConfigValue<SolidCoreSetting>("refreshTokenTtl"),
+        );
+        return (refreshTokenTtlSeconds + STATE_TTL_BUFFER_SECONDS) * 1000;
     }
 
-    private getKey(userId: number): string {
-        return `user-${userId}`;
+    private isRefreshTokenState(state: unknown): state is RefreshTokenState {
+        return (
+            !!state &&
+            typeof state === 'object' &&
+            'currentRefreshToken' in state &&
+            'previousRefreshToken' in state
+        );
     }
 
-    getCurrentRefreshTokenState(userId: number): Promise<RefreshTokenState | undefined> {
-        return this.cacheManager.get(this.getKey(userId));
+    private isWithinGraceWindow(state: RefreshTokenState): boolean {
+        // TRANSITIONAL - safe to delete one refreshTokenTtl after this ships.
+        //
+        // Entries written before previousValidUntil existed carry no deadline
+        // to test. They are accepted so that the deploy rejects nobody: a tab
+        // that legitimately rotated moments earlier keeps working. The cost is
+        // that for such an entry the previous token stays acceptable until its
+        // own JWT `exp` rather than for 60s - which is exactly how the old code
+        // already behaved whenever its in-process timer was lost to a restart,
+        // so this is an unfixed pre-existing case, not a new one.
+        //
+        // It self-heals: the user's next rotation writes a new-format state
+        // with a deadline. Once every pre-deploy entry has rotated or expired
+        // (one refreshTokenTtl), this branch is unreachable - drop it, and the
+        // undefined case becomes a rejection.
+        if (state.previousValidUntil === undefined) {
+            return true;
+        }
+        return Date.now() < state.previousValidUntil;
     }
 }

package/src/services/setting.service.ts

@@ -16,6 +16,8 @@ import { ModuleMetadataRepository } from 'src/repository/module-metadata.reposit
 import type { SolidCoreSetting } from './settings/default-settings-provider.service';
 import { Logger } from '@nestjs/common';
 import { EncryptionService } from './encryption.service';
+import { sanitizeStoredMediaFileName } from './media-storage.utils';
+import { isDangerousMediaFile } from 'src/constants/media-file-types';
 
 
 @Injectable()
@@ -357,8 +359,13 @@ export class SettingService {
     // Handle uploaded files
     if (uploadedFiles?.length) {
       for (const file of uploadedFiles) {
+        if (isDangerousMediaFile(file)) {
+          throw new BadRequestException('Dangerous file types are not allowed for settings.');
+        }
+
         const settingKey = file.fieldname;
-        const relativeFileName = `${file.filename}-${file.originalname}`;
+        // originalname is attacker-controlled and feeds straight into a storage path.
+        const relativeFileName = `${file.filename}-${sanitizeStoredMediaFileName(file.originalname)}`;
 
         // Read file from local disk (where Multer stores uploads) and write to storage
         // The path builder constructs the provider-appropriate storage path

package/src/services/settings/default-settings-provider.service.ts

@@ -6,10 +6,18 @@ import {
   SettingDefinition,
   SettingLevel,
 } from "src/interfaces";
+import { getDefaultThemeKey, getThemesByMode } from "src/theme/theme-registry";
 
 export const DEFAULT_MEDIA_UPLOAD_DIR = "media-uploads";
 export const DEFAULT_MEDIA_FILE_STORAGE_DIR = "media-files-storage";
 
+// Seeded setting values are written once and never overwritten, so an unparseable
+// env var would persist. Fall back whenever it is missing or not a positive number.
+const timeoutFromEnv = (value: string | undefined, fallback: number): number => {
+  const parsed = Number(value);
+  return Number.isFinite(parsed) && parsed > 0 ? parsed : fallback;
+};
+
 // 1.
 const getSolidCoreSettings = (isProd: boolean) =>
   [
@@ -217,14 +225,44 @@ const getSolidCoreSettings = (isProd: boolean) =>
     },
     {
       moduleName: "solid-core",
-      key: "enableDarkMode",
+      key: "showThemeToggle",
       value: true,
       level: SettingLevel.SystemAdminEditable,
-      label: "Enable Dark Mode",
+      label: "Show Theme Toggle",
       group: "app-settings",
       sortOrder: 120,
       controlType: "boolean",
-      helpText: "Enables dark theme support for frontend surfaces that honor the global appearance setting.",
+      helpText: "Shows the theme toggle in the frontend so users can switch between light and dark themes.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "lightTheme",
+      value: getDefaultThemeKey("light"),
+      level: SettingLevel.SystemAdminEditable,
+      label: "Light Theme",
+      group: "app-settings",
+      sortOrder: 125,
+      controlType: "selectionStatic",
+      options: getThemesByMode("light").map((theme) => ({
+        label: theme.label,
+        value: theme.key,
+      })),
+      helpText: "Selects the theme used whenever the application is in light mode.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "darkTheme",
+      value: getDefaultThemeKey("dark"),
+      level: SettingLevel.SystemAdminEditable,
+      label: "Dark Theme",
+      group: "app-settings",
+      sortOrder: 126,
+      controlType: "selectionStatic",
+      options: getThemesByMode("dark").map((theme) => ({
+        label: theme.label,
+        value: theme.key,
+      })),
+      helpText: "Selects the theme used whenever the application is in dark mode.",
     },
     {
       moduleName: "solid-core",
@@ -494,6 +532,20 @@ const getSolidCoreSettings = (isProd: boolean) =>
       ],
       helpText: "Default storage implementation used for file handling, such as local disk or S3.",
     },
+    {
+      moduleName: "solid-core",
+      key: "maxMediaFileSizeMb",
+      value: (() => {
+        const parsedMb = Number(process.env.AB_MEDIA_MAX_FILE_SIZE_MB);
+        return Number.isFinite(parsedMb) && parsedMb > 0 ? parsedMb : 100;
+      })(),
+      level: SettingLevel.SystemAdminReadonly,
+      label: "Max Media File Size (MB)",
+      group: "storage-settings",
+      sortOrder: 45,
+      controlType: "numeric",
+      helpText: "Global upload size limit enforced by Multer under every per-field mediaMaxSizeKb restriction. Read-only here: it's applied once at process start, so changing AB_MEDIA_MAX_FILE_SIZE_MB requires an app restart to take effect - editing this in the admin UI would not do that.",
+    },
 
     // aws-s3-settings-provider.service.ts
     {
@@ -1211,6 +1263,77 @@ const getSolidCoreSettings = (isProd: boolean) =>
       sortOrder: 200,
       controlType: "boolean",
     },
+    {
+      moduleName: "solid-core",
+      key: "mpinEnabled",
+      value: false,
+      level: SettingLevel.SystemAdminEditable,
+      label: "Enable MPIN Sign-in",
+      group: "authentication-settings",
+      sortOrder: 210,
+      controlType: "boolean",
+      helpText:
+        "Allows users to set a short device PIN for faster sign-in. Every MPIN route returns 404 while this is off.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "mpinRegex",
+      value: process.env.IAM_MPIN_REGEX ?? "^\\d{4,6}$",
+      level: SettingLevel.SystemAdminEditable,
+      label: "MPIN Format",
+      group: "authentication-settings",
+      sortOrder: 211,
+      controlType: "shortText",
+      helpText:
+        "Regular expression the MPIN must match. Sole authority on MPIN length - the default allows 4 to 6 digits. Predictable PINs (repeated or sequential digits) are rejected separately.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "mpinMaxFailedAttempts",
+      value: parseInt(process.env.IAM_MPIN_MAX_FAILED_ATTEMPTS ?? "5", 10),
+      level: SettingLevel.SystemAdminEditable,
+      label: "MPIN Attempts Before Lockout",
+      group: "authentication-settings",
+      sortOrder: 212,
+      controlType: "numeric",
+      helpText:
+        "Cumulative failed attempts that trigger a temporary lockout. The counter resets only on a successful MPIN sign-in, not when the lockout expires.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "mpinLockoutDuration",
+      value: parseInt(process.env.IAM_MPIN_LOCKOUT_DURATION ?? "900", 10),
+      level: SettingLevel.SystemAdminEditable,
+      label: "MPIN Lockout Duration (seconds)",
+      group: "authentication-settings",
+      sortOrder: 213,
+      controlType: "numeric",
+      helpText: "How long the temporary lockout lasts.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "mpinMaxTotalFailedAttempts",
+      value: parseInt(process.env.IAM_MPIN_MAX_TOTAL_FAILED_ATTEMPTS ?? "10", 10),
+      level: SettingLevel.SystemAdminEditable,
+      label: "MPIN Attempts Before Permanent Deactivation",
+      group: "authentication-settings",
+      sortOrder: 214,
+      controlType: "numeric",
+      helpText:
+        "Cumulative failed attempts that permanently disable MPIN on that device. Must exceed the lockout threshold. The account itself is never locked - the user signs in normally and sets MPIN up again.",
+    },
+    {
+      moduleName: "solid-core",
+      key: "mpinMaxDevicesPerUser",
+      value: parseInt(process.env.IAM_MPIN_MAX_DEVICES_PER_USER ?? "5", 10),
+      level: SettingLevel.SystemAdminEditable,
+      label: "Max MPIN Devices Per User",
+      group: "authentication-settings",
+      sortOrder: 215,
+      controlType: "numeric",
+      helpText:
+        "At the cap the least recently used credential is evicted rather than the setup rejected, so repeated app reinstalls cannot lock a user out of MPIN setup.",
+    },
     // queues-settings-provider.service.ts
     {
       moduleName: "solid-core",
@@ -1477,7 +1600,7 @@ const getSolidCoreSettings = (isProd: boolean) =>
     {
       moduleName: "solid-core",
       key: "uiTestDefaultTimeoutMs",
-      value: 30000,
+      value: timeoutFromEnv(process.env.COMMON_UI_TEST_DEFAULT_TIMEOUT_MS, 30000),
       level: SettingLevel.SystemAdminEditable,
       label: "UI Test Default Timeout (ms)",
       group: "testing-settings",
@@ -1488,7 +1611,10 @@ const getSolidCoreSettings = (isProd: boolean) =>
     {
       moduleName: "solid-core",
       key: "uiTestNavigationTimeoutMs",
-      value: 30000,
+      value: timeoutFromEnv(
+        process.env.COMMON_UI_TEST_NAVIGATION_TIMEOUT_MS,
+        timeoutFromEnv(process.env.COMMON_UI_TEST_DEFAULT_TIMEOUT_MS, 30000),
+      ),
       level: SettingLevel.SystemAdminEditable,
       label: "UI Test Navigation Timeout (ms)",
       group: "testing-settings",