rimecms 0.31.5 → 0.32.1

package/dist/core/auth/staff/derive.js

@@ -0,0 +1,58 @@
+import { access } from '../../../util/index.js';
+import { UsersRound } from '@lucide/svelte';
+import cloneDeep from 'clone-deep';
+export const staffCollection = {
+    label: { singular: 'User', plural: 'Users' },
+    panel: {
+        description: 'Manage who can access your admin panel',
+        group: 'system'
+    },
+    auth: {
+        type: 'password',
+        roles: ['admin', 'staff']
+    },
+    icon: UsersRound,
+    fields: [],
+    access: {
+        // Any staff member, not just an admin: the panel shows who made a document and who is
+        // holding its edit lock, and that name has to be readable by whoever is looking at it.
+        // `roles` keeps its own admin-only read (auth/augment.ts).
+        read: (user) => access.isStaff(user),
+        create: (user) => access.isAdmin(user),
+        delete: (user) => access.isAdmin(user),
+        update: (user, { id }) => access.isAdminOrMe(user, id)
+    }
+};
+export const getStaffCollection = ({ roles: incomingRoles = [], fields = [], access, panel, label } = {}) => {
+    const staffConfig = cloneDeep(staffCollection);
+    let roles = incomingRoles.map((role) => typeof role === 'string' ? { value: role } : role);
+    if (roles) {
+        const hasAdminRole = roles.find((role) => role.value === 'admin');
+        const otherRoles = roles.filter((role) => role.value !== 'admin');
+        // Add admin role on Staff collection if not present
+        if (!hasAdminRole) {
+            roles = [{ value: 'admin' }, ...roles];
+        }
+        // If there is no other roles than admin add a staff role
+        if (otherRoles.length === 0) {
+            roles.push({ value: 'staff' });
+        }
+        staffConfig.auth.roles = roles.map((role) => role.value);
+    }
+    if (fields) {
+        staffConfig.fields.push(...fields);
+    }
+    if (access) {
+        staffConfig.access = {
+            ...staffConfig.access,
+            ...access
+        };
+    }
+    if (panel?.group) {
+        staffConfig.panel = { ...staffConfig.panel, group: panel?.group };
+    }
+    if (label) {
+        staffConfig.label = label;
+    }
+    return staffConfig;
+};

package/dist/core/auth/tables.d.ts

@@ -0,0 +1,38 @@
+import type { ColumnDeclaration, TableDeclaration } from '../adapter.js';
+/**
+ * The storage auth needs, said by auth.
+ *
+ * These four tables were a string constant in `adapter-sqlite/generate-schema/templates.server.ts`,
+ * pushed onto every schema whether or not anything signed in; the api-key table was a fifth behind
+ * a `authConfig(prototype)?.type === 'apiKey'` sniff in the generator; and the column below was
+ * `templateHasAuth`, which decided whether to add the super-admin flag by testing
+ * `slug === 'staff'`. All of it was the database layer knowing what auth is.
+ *
+ * The column order is the order those templates emitted, and it is load-bearing: field order is
+ * column order, so a reorder is a migration nobody asked for (`CONTRIBUTING.md`, rule 2).
+ */
+/**
+ * The collection auth derives for panel sign-in.
+ *
+ * The literal was in the schema generator, which is what made the database layer know a `staff`
+ * collection exists and is the one with a super-admin flag. It is auth's, because auth is what
+ * creates it — see `staff/configure.ts`.
+ */
+export declare const STAFF_SLUG = "staff";
+export declare const authTables: (config: {
+    collections?: {
+        auth?: unknown;
+        slug: string;
+    }[];
+}) => TableDeclaration[];
+/**
+ * What a collection that signs in carries on its own row.
+ *
+ * The link to the better-auth user, and — on the collection auth itself derived — the super-admin
+ * flag. `templateHasAuth` decided the second by testing `slug === 'staff'`; the feature that made
+ * that collection is the thing that knows which it is.
+ */
+export declare const authColumns: (config: {
+    slug: string;
+    auth?: unknown;
+}) => ColumnDeclaration[];

package/dist/core/auth/tables.js

@@ -0,0 +1,157 @@
+/**
+ * The storage auth needs, said by auth.
+ *
+ * These four tables were a string constant in `adapter-sqlite/generate-schema/templates.server.ts`,
+ * pushed onto every schema whether or not anything signed in; the api-key table was a fifth behind
+ * a `authConfig(prototype)?.type === 'apiKey'` sniff in the generator; and the column below was
+ * `templateHasAuth`, which decided whether to add the super-admin flag by testing
+ * `slug === 'staff'`. All of it was the database layer knowing what auth is.
+ *
+ * The column order is the order those templates emitted, and it is load-bearing: field order is
+ * column order, so a reorder is a migration nobody asked for (`CONTRIBUTING.md`, rule 2).
+ */
+/**
+ * The collection auth derives for panel sign-in.
+ *
+ * The literal was in the schema generator, which is what made the database layer know a `staff`
+ * collection exists and is the one with a super-admin flag. It is auth's, because auth is what
+ * creates it — see `staff/configure.ts`.
+ */
+export const STAFF_SLUG = 'staff';
+const timestampsMs = [
+    { name: 'createdAt', type: 'timestampMs', notNull: true },
+    { name: 'updatedAt', type: 'timestampMs', notNull: true }
+];
+/** A foreign key onto the better-auth user, which three of the tables below carry. */
+const authUserRef = {
+    table: '$authUsers',
+    onDelete: 'cascade'
+};
+export const authTables = (config) => {
+    const collections = config.collections ?? [];
+    // Nothing signs in, so none of this is needed. The generator used to emit all four regardless.
+    // In practice `configure` derives the staff collection for every config, so this is true today
+    // only for a build that has dropped it — which is exactly when emitting them would be wrong.
+    if (!collections.some((collection) => collection.auth))
+        return [];
+    const tables = [
+        {
+            slug: '$authUsers',
+            columns: [
+                { name: 'id', type: 'text', primary: true },
+                { name: 'name', type: 'text', notNull: true },
+                { name: 'email', type: 'text', notNull: true, unique: true },
+                { name: 'emailVerified', type: 'boolean', notNull: true },
+                { name: 'image', type: 'text' },
+                ...timestampsMs,
+                { name: 'role', type: 'text' },
+                { name: 'banned', type: 'boolean' },
+                { name: 'banReason', type: 'text' },
+                { name: 'banExpires', type: 'timestampMs' },
+                { name: 'type', type: 'text', notNull: true }
+            ]
+        },
+        {
+            slug: '$authSessions',
+            columns: [
+                { name: 'id', type: 'text', primary: true },
+                { name: 'expiresAt', type: 'timestampMs', notNull: true },
+                { name: 'token', type: 'text', notNull: true, unique: true },
+                ...timestampsMs,
+                { name: 'ipAddress', type: 'text' },
+                { name: 'userAgent', type: 'text' },
+                { name: 'userId', type: 'text', notNull: true, references: authUserRef },
+                { name: 'impersonatedBy', type: 'text' }
+            ]
+        },
+        {
+            slug: '$authAccounts',
+            columns: [
+                { name: 'id', type: 'text', primary: true },
+                { name: 'accountId', type: 'text', notNull: true },
+                { name: 'providerId', type: 'text', notNull: true },
+                { name: 'userId', type: 'text', notNull: true, references: authUserRef },
+                { name: 'accessToken', type: 'text' },
+                { name: 'refreshToken', type: 'text' },
+                { name: 'idToken', type: 'text' },
+                { name: 'accessTokenExpiresAt', type: 'timestampMs' },
+                { name: 'refreshTokenExpiresAt', type: 'timestampMs' },
+                { name: 'scope', type: 'text' },
+                { name: 'password', type: 'text' },
+                ...timestampsMs
+            ]
+        },
+        {
+            slug: '$authVerifications',
+            columns: [
+                { name: 'id', type: 'text', primary: true },
+                { name: 'identifier', type: 'text', notNull: true },
+                { name: 'value', type: 'text', notNull: true },
+                { name: 'expiresAt', type: 'timestampMs', notNull: true },
+                { name: 'createdAt', type: 'timestampMs' },
+                { name: 'updatedAt', type: 'timestampMs' }
+            ]
+        }
+    ];
+    // The api-key store. Unconditional, because `configurePlugins` registers better-auth's api-key
+    // plugin unconditionally, and 1.7.4 checks at startup that every registered plugin has its
+    // table:
+    //
+    // ```
+    // ERROR [Better Auth]: Drizzle schema mismatch
+    //   Missing tables
+    //     apikey
+    // ```
+    //
+    // Making the *plugin* conditional instead would make `rime.auth`'s inferred type depend on
+    // whether a config happens to declare an apiKey collection. Its slug has no camel hump on
+    // purpose: the plugin looks the table up as `apikey`.
+    {
+        tables.push({
+            slug: '$apikey',
+            columns: [
+                { name: 'id', type: 'text', primary: true },
+                { name: 'name', type: 'text' },
+                { name: 'start', type: 'text' },
+                { name: 'prefix', type: 'text' },
+                { name: 'key', type: 'text', notNull: true },
+                { name: 'referenceId', type: 'text', notNull: true, references: authUserRef },
+                { name: 'configId', type: 'text', notNull: true, defaultValue: 'default' },
+                { name: 'refillInterval', type: 'integer' },
+                { name: 'refillAmount', type: 'integer' },
+                { name: 'lastRefillAt', type: 'timestamp' },
+                { name: 'enabled', type: 'boolean', defaultValue: true },
+                { name: 'rateLimitEnabled', type: 'boolean', defaultValue: true },
+                { name: 'rateLimitTimeWindow', type: 'integer', defaultValue: 86400000 },
+                { name: 'rateLimitMax', type: 'integer', defaultValue: 10 },
+                { name: 'requestCount', type: 'integer' },
+                { name: 'remaining', type: 'integer' },
+                { name: 'lastRequest', type: 'timestamp' },
+                { name: 'expiresAt', type: 'timestamp' },
+                { name: 'createdAt', type: 'timestamp', notNull: true },
+                { name: 'updatedAt', type: 'timestamp', notNull: true },
+                { name: 'permissions', type: 'text' },
+                { name: 'metadata', type: 'text' }
+            ]
+        });
+    }
+    return tables;
+};
+/**
+ * What a collection that signs in carries on its own row.
+ *
+ * The link to the better-auth user, and — on the collection auth itself derived — the super-admin
+ * flag. `templateHasAuth` decided the second by testing `slug === 'staff'`; the feature that made
+ * that collection is the thing that knows which it is.
+ */
+export const authColumns = (config) => 
+// Not an auth collection: no link, no flag. `enabled` used to gate this through a
+// `FeatureDefinition.columns` seam only auth ever implemented.
+!config.auth
+    ? []
+    : [
+        { name: 'authUserId', type: 'text', notNull: true, references: authUserRef },
+        ...(config.slug === STAFF_SLUG
+            ? [{ name: 'isSuperAdmin', type: 'boolean' }]
+            : [])
+    ];

package/dist/core/auth/types.d.ts

@@ -0,0 +1,47 @@
+import type { BaseDoc } from '../prototype/types.js';
+import type { Dic } from '../../util/types.js';
+/**
+ * What a document of a collection that signs in carries beyond a plain one.
+ *
+ * Was in `core/prototype/types.ts`, spelled into the `Docs` registry by core.
+ */
+export type GenericAuthDoc = BaseDoc & {
+    apiKeyId?: string;
+    authUserId?: string;
+    roles?: string[];
+} & Dic;
+declare module '$lib/core/prototype/types.js' {
+    interface FeatureDocTypes {
+        auth: GenericAuthDoc;
+    }
+}
+export type User = {
+    id: string;
+    name: string;
+    email: string;
+    roles: string[];
+    isStaff?: boolean;
+    isSuperAdmin?: boolean;
+};
+import type { Option } from '../../fields/types.js';
+import type { Access } from '../config/types.js';
+import type { CollectionLabel } from '../prototype/collection/types.js';
+import type { FieldBuilder } from '../fields/builders/field-builder.js';
+import type { Field } from '../../fields/types.js';
+/** What an author writes under `auth`, and what `staff` may be extended with. */
+export type CollectionAuthConfig = ({
+    type: 'password';
+} | {
+    type: 'apiKey';
+}) & {
+    roles?: (string | Option)[];
+};
+export type AdditionalStaffConfig = {
+    roles?: (string | Option)[];
+    panel?: {
+        group?: string;
+    };
+    access?: Access;
+    label?: CollectionLabel;
+    fields?: FieldBuilder<Field>[];
+};

package/dist/core/auth/user.server.d.ts

@@ -0,0 +1,43 @@
+import type { Adapter } from '../adapter.js';
+import type { CollectionSlug } from '../prototype/types.js';
+import type { User } from './types.js';
+/**
+ * The three reads auth needs about its own rows.
+ *
+ * They were `adapter.auth.isSuperAdmin`, `.getBetterAuthUserId` and `.getUserAttributes` — a third
+ * of a facade on the `Adapter` interface, for one feature. Each is
+ * `select … from <a prototype's table> where <a column> = ?`, which is what `findMany` already is;
+ * what made them look like adapter work was that all three named a collection called `staff` and
+ * the database layer was the only place that name appeared.
+ *
+ * It appears here instead, once, as `STAFF_SLUG` — and it belongs here because this feature is
+ * what derives that collection (`staff/configure.ts`).
+ *
+ * > **These read rows, not documents.** `adapter.collection(slug).findMany` runs no hooks and no
+ * > access checks, which is deliberate and load-bearing: all three run *during* authentication,
+ * > before there is a user to check anything against. Going through `rime.collection(slug).find()`
+ * > would recurse — the access check needs the user this call is resolving.
+ */
+/**
+ * Whether this staff member is the super-admin.
+ *
+ * A wrong answer here is a privilege escalation rather than a bug, so it asks for the row and the
+ * flag together: no row matching *both* means no.
+ */
+export declare const isSuperAdmin: (adapter: Adapter, userId: string) => Promise<boolean>;
+/** The better-auth user a collection row is linked to, or `null` when it is linked to none. */
+export declare const betterAuthUserId: (adapter: Adapter, args: {
+    slug: CollectionSlug;
+    id: string;
+}) => Promise<string | null>;
+/**
+ * The session user, read off the collection row a better-auth user is linked to.
+ *
+ * The members are named rather than spread, which is what the hand-written `db.select()` did too:
+ * this object becomes `event.locals.user` and reaches the client through `toPublicUser`, so what
+ * it carries is a decision, not whatever the read happened to return.
+ */
+export declare const userAttributes: (adapter: Adapter, args: {
+    authUserId: string;
+    slug: CollectionSlug;
+}) => Promise<User | undefined>;

package/dist/core/auth/user.server.js

@@ -0,0 +1,73 @@
+import { STAFF_SLUG } from './tables.js';
+/**
+ * The three reads auth needs about its own rows.
+ *
+ * They were `adapter.auth.isSuperAdmin`, `.getBetterAuthUserId` and `.getUserAttributes` — a third
+ * of a facade on the `Adapter` interface, for one feature. Each is
+ * `select … from <a prototype's table> where <a column> = ?`, which is what `findMany` already is;
+ * what made them look like adapter work was that all three named a collection called `staff` and
+ * the database layer was the only place that name appeared.
+ *
+ * It appears here instead, once, as `STAFF_SLUG` — and it belongs here because this feature is
+ * what derives that collection (`staff/configure.ts`).
+ *
+ * > **These read rows, not documents.** `adapter.collection(slug).findMany` runs no hooks and no
+ * > access checks, which is deliberate and load-bearing: all three run *during* authentication,
+ * > before there is a user to check anything against. Going through `rime.collection(slug).find()`
+ * > would recurse — the access check needs the user this call is resolving.
+ */
+/**
+ * Whether this staff member is the super-admin.
+ *
+ * A wrong answer here is a privilege escalation rather than a bug, so it asks for the row and the
+ * flag together: no row matching *both* means no.
+ */
+export const isSuperAdmin = async (adapter, userId) => {
+    const [found] = await adapter.collection(STAFF_SLUG).findMany({
+        query: {
+            where: { and: [{ id: { equals: userId } }, { isSuperAdmin: { equals: true } }] }
+        },
+        select: ['id'],
+        limit: 1
+    });
+    return !!found;
+};
+/** The better-auth user a collection row is linked to, or `null` when it is linked to none. */
+export const betterAuthUserId = async (adapter, args) => {
+    const [row] = await adapter.collection(args.slug).findMany({
+        query: { where: { id: { equals: args.id } } },
+        select: ['authUserId'],
+        limit: 1
+    });
+    return row?.authUserId ?? null;
+};
+/**
+ * The session user, read off the collection row a better-auth user is linked to.
+ *
+ * The members are named rather than spread, which is what the hand-written `db.select()` did too:
+ * this object becomes `event.locals.user` and reaches the client through `toPublicUser`, so what
+ * it carries is a decision, not whatever the read happened to return.
+ */
+export const userAttributes = async (adapter, args) => {
+    const isStaff = args.slug === STAFF_SLUG;
+    const [row] = await adapter.collection(args.slug).findMany({
+        query: { where: { authUserId: { equals: args.authUserId } } },
+        // `isSuperAdmin` is only a column on the collection this feature derives. A `select` naming a
+        // column the table does not have is dropped, so asking for it everywhere would also work —
+        // but then nothing would say that only one collection has it.
+        select: isStaff
+            ? ['id', 'name', 'email', 'roles', 'isSuperAdmin']
+            : ['id', 'name', 'email', 'roles'],
+        limit: 1
+    });
+    if (!row)
+        return undefined;
+    return {
+        id: row.id,
+        name: row.name,
+        email: row.email,
+        roles: row.roles,
+        ...(isStaff ? { isSuperAdmin: row.isSuperAdmin === true } : {}),
+        isStaff
+    };
+};

package/dist/core/auth/util.d.ts

@@ -0,0 +1,13 @@
+import type { CollectionAuthConfig } from './types.js';
+/**
+ * Checks if a collection configuration has authentication capabilities
+ * @example
+ * if (isAuthConfig(collection)) {
+ *   // Handle auth-specific functionality
+ * }
+ */
+export declare const isAuthConfig: <T extends {
+    auth?: boolean | CollectionAuthConfig;
+}>(config: T) => config is T & {
+    auth: true | CollectionAuthConfig;
+};

package/dist/core/auth/validate-config.d.ts

@@ -0,0 +1,13 @@
+import type { BuiltCollection } from '../config/types.js';
+/**
+ * What a collection declaring `auth` has to look like.
+ *
+ * These rules were in `config/validate.server.ts`, which imported `isAuthConfig` to find the
+ * collections they applied to — core knowing what an auth collection is, to enforce auth's own
+ * requirements. They are asked through `FeatureDefinition.validate` now, and only of configs where
+ * `enabled` is true, so nothing here re-tests for `auth`.
+ *
+ * The messages are unchanged: they are what a config author sees, and the e2e suite matches on
+ * some of them.
+ */
+export declare const validateAuth: (config: BuiltCollection) => string[];

package/dist/core/auth/validate-config.js

@@ -0,0 +1,42 @@
+import { isFormField } from '../fields/util.js';
+import { SelectFieldBuilder } from '../../fields/select/index.js';
+/**
+ * What a collection declaring `auth` has to look like.
+ *
+ * These rules were in `config/validate.server.ts`, which imported `isAuthConfig` to find the
+ * collections they applied to — core knowing what an auth collection is, to enforce auth's own
+ * requirements. They are asked through `FeatureDefinition.validate` now, and only of configs where
+ * `enabled` is true, so nothing here re-tests for `auth`.
+ *
+ * The messages are unchanged: they are what a config author sees, and the e2e suite matches on
+ * some of them.
+ */
+export const validateAuth = (config) => {
+    // Not an auth collection: nothing here applies. `enabled` used to gate this, through a seam
+    // only auth ever implemented.
+    if (!config.auth)
+        return [];
+    const errors = [];
+    // A versioned auth collection would put credentials on a version row and leave the sign-in path
+    // reading whichever version happened to be published.
+    if (config.versions) {
+        errors.push(`Auth collections can't be versionned (${config.slug})`);
+    }
+    const formFields = config.fields.filter(isFormField);
+    const rolesField = formFields
+        .filter((f) => f.name === 'roles')
+        .filter((f) => f instanceof SelectFieldBuilder)[0];
+    const nameField = formFields.filter((f) => f.name === 'name')[0];
+    const emailField = formFields.find((f) => f.name === 'email' && f.type === 'email');
+    if (!rolesField)
+        errors.push(`Field roles is missing in collection ${config.slug}`);
+    if (!emailField && config.auth?.type !== 'apiKey')
+        errors.push(`Field email is missing in collection ${config.slug}`);
+    if (!nameField)
+        errors.push(`Field name is missing in collection ${config.slug}`);
+    // Guarded: the message above already says the field is missing, and reading `.get` off nothing
+    // would throw here instead of reporting.
+    if (rolesField && !rolesField.get.many)
+        errors.push(`Field roles must have "many" enabled : select('roles').options(...).many(), even with a single option`);
+    return errors;
+};