[travist]

Stacked on #111. Retarget to master once #111 merges.

Why

A customer database was cloned with the wrong --dst-db-secret, leaving project settings (and possibly encrypted fields) under a key the destination server does not use. There was no safe way to re-encrypt a database in place. Looking into it turned up two clone bugs.

Changes

formio rekey (new command)

formio rekey <mongo_url> --new-db-secret NEW \
  --old-db-secret OLD1 [--old-db-secret OLD2] [--dry-run] [--project <ids>]

• Re-encrypts projects.settings_encrypted with the new DB_SECRET. Encrypted field values are re-encrypted with the project's own settings.secret when it has one, otherwise with the new DB_SECRET, which is how the server picks the key.
• Each value is tried with its target secret first and skipped if it already opens, so the command is safe to re-run. Otherwise each --old-db-secret is tried in turn, and the re-encrypted value is read back before writing.
• Covers fields inside datagrid/editgrid rows and containers, custom submission collections, and submission revisions (unless --no-submission-revisions). Deleted documents are included.
• Each write only applies if the stored ciphertext is unchanged since it was read, so a value edited mid-run is never overwritten.
• Values no secret can open, and projects whose settings cannot be decrypted, are reported and left untouched, and the command exits non-zero.

The server's built-in DB_SECRET_OLD rotation (src/util/updateSecret.js in formio-server) isn't a substitute. It reads project.settings.secret from the raw document, where it is always undefined. It also misses nested values, skips falsy values and revisions, and fires its field updates without awaiting them.

Clone fixes

• Encrypted fields inside datagrid/editgrid rows were not re-encrypted. Paths like data.grid.field were looked up against array data, found nothing, and those values silently kept the source secret. The form is now walked against the submission data itself.
• Custom submission collections were misnamed. The server strips everything but letters and digits from the project and collection names (myproject_records). The clone used the raw names (my-project_records), so for projects with symbols in their name, submissions landed where the server never reads them. The clone now uses the server's naming and warns when the destination still holds submissions in a misnamed collection.
• Revisions of custom collections were never cloned. They were read from and written to the default submissionrevisions instead of <collection>_revisions.

Refactoring

• The crypto helpers moved to src/encryption.js and the connection helpers to src/db.js. decrypt() no longer logs every failed attempt, which rekey would trigger once per wrong key.
• Removed src/eachComponentAsync.js, which is now unused.

Testing

• test/cloner/rekey.js (19 tests): value walking, dry run, full re-key including nested, revision and custom-collection values, re-run idempotency, project-secret targeting, --project filtering, undecryptable settings and values, --no-submission-revisions, and the concurrent-change guard.
• New clone tests: a datagrid with encrypted fields, server-style collection naming, custom-collection revisions, and the misnamed-collection warning. The datagrid and naming tests fail against the previous code.
• CLI parsing tests for rekey.
• mocha test/cloner/index.js: 269 passing. yarn test:cli: 16 passing. Each commit passes on its own.
• Also run by hand against a 2,500-submission database: dry run, real run, then a re-run with nothing left to do.

🤖 Generated with Claude Code