Security: Rules

Access rules let you go beyond coarse “can read / can write” toggles: you can allow or deny specific operations on specific database objects or file paths, optionally driven by a SQL expression (a full SQL query, not a bare condition). At the time of writing, rules are configured per role (there is no separate rules UI for users without going through a role).

Roles and database-backed user storage are covered in Users & auth. For rules to be meaningful in production, you typically want users stored in the database and roles assigned as described there.

Alpha — The rules screens are labeled Access Rules (alpha version). Behaviour and available operations may change between releases; verify on your version after upgrades.

Where to open rules

Open Users & Auth details → Edit roles, choose a role, then scroll to the bottom of Role Details. You will see two buttons:

DB ACCESS RULES — rules for SQLite / database operations.
FS ACCESS RULES — rules for file-system operations (served files and folders).

Database access rules

This screen lists rules for database access (subtitle: “Database access rules management”). Use Add rule to create a rule.

Each rule defines:

Subject — a table or view name, or * to match any table/view (as described in the app).
Operation — which database operation the rule applies to (e.g. reads, writes, execution of SQL).
Allow — a simple allow/deny when no custom expression is used. The UI notes that this is used only if SQL expression is not set.
SQL expression — optional. If set, it must be valid SQL that returns at least one column and one row; that result is interpreted as allow/deny and overrides the simple Allow checkbox. See SQL expression variables and placeholders.

Database access rules list — Database access rules: list of rules for the role

Database rule details: subject, operation, allow, SQL expression — Editing a database rule: subject, operation, Allow, and SQL expression

File system access rules

This screen lists rules for file system access (subtitle: “File system access rules management”). Again, use Add rule to create a rule.

Each rule defines:

Subject — a directory or file path the rule applies to (relative to the document root / shared tree as enforced by the server).
Operation — the file operation (examples include listing directory contents, upload, download, delete, rename, thumbnails, zip download, and similar).
Allow — simple allow/deny when no SQL expression is set (same note as for DB rules).
SQL expression — optional; same rules as for DB rules (a full SQL query returning at least one column and one row). See SQL expression variables and placeholders.

File system access rules list — File system access rules: list of rules for the role

SQL expression variables and placeholders

The SQL expression field must contain a complete, valid SQL query (not just a predicate or WHERE fragment). It must return at least one column and one row; the engine uses that cell as the outcome (allow/deny). A standalone condition such as :operation = 'READ_TABLE' is unlikely to work because it is not a proper SELECT with a result set.

You can reference bound values using placeholders in the form :name.

Placeholder syntax

Placeholders must match PARAM_PATTERN: :([a-zA-Z_][a-zA-Z0-9_.[\]]*) — so names like :param.files[] are valid.

Always available

Variable in expression (`:name`)	Meaning
`:user.id`	User name
`:user.role`	User role
`:user.rootDir`	User root directory
`:user.usedStorage`	User used storage
`:subject`	Table name, path, or special constant (see below)
`:operation`	Operation string (see below)

param.* keys are provided by the handler (and depend on operation and subject).

Each operation in the tables below (READ_TABLE, READ_CELL, ZIP_DOWNLOAD, and so on) is triggered by the same server-side paths as the corresponding REST API entry points. Full endpoint documentation is in the API Documentation section of this site.

Database — table name is `subject` unless noted

Operation	Extra `param.*` keys	Notes
`READ_TABLE`	`columns`, `offset`, `limit`, `sort`, `sortDir`, `includeRowId`, `rowsAsObjects`, `includeTotal`, `filters`	`filters` is JSON; several fields use `""` when absent; booleans as Boolean.
`READ_CELL`	`column`, `filters`	`column` from request; `filters` JSON string.
`INSERT`	`values`	JSON string of row.
`UPDATE`	`values`, `filters`	Both JSON strings.
`DELETE`	`filters`	JSON string.
`READ_SCHEMA`	(none)	`operationParams` is null; `subject` is table name or `*`.
`EXECUTE`	(none)

Files — path is `subject`

Operation	Extra `param.*` keys	Notes
`DOWNLOAD`	(none)	null params.
`THUMBNAIL`	(none)	null params.
`LIST_CONTENTS`	`sort`, `search`, `sort-reversed`	Defaults applied when query params are missing; fixed map: `"default"`, `""`, `"false"`.
`RENAME`	`name`	New file name.
`NEW_FOLDER`	`name`	New folder name.
`UPLOAD`	`contentLength`	long; request body size.
`DELETE`	`files.size`, `files[]`	Count + JSON array string of names. Keys become `param.files.size` and `param.files[]`.
`COPY_MOVE`	`action`, `files.size`, `files[]`	`action` is `"copy"` or `"move"`; same `files.*` as delete.
`ZIP_DOWNLOAD`	`level`, `uncompressed`, `files.size`, `files[]`	`level` may be null; `uncompressed` is `List<String>`; `files[]` is JSON array string.

Simple SQL expression examples

Each example is a full SELECT that always returns one row and one numeric column (1 = allow, 0 = deny in this pattern). The dialect matches the app’s SQLite usage; adapt placeholders to your rule.

Allow only when reading the orders table — SELECT CASE WHEN :operation = 'READ_TABLE' AND :subject = 'orders' THEN 1 ELSE 0 END
Deny uploads when the body is larger than 10 MiB — SELECT CASE WHEN :operation = 'UPLOAD' AND CAST(:param.contentLength AS INTEGER) > 10485760 THEN 0 ELSE 1 END

These are illustrative; combine with :user.* and :param.* as needed for your policy.