feat: rclone-crypt folder vault PoC by dschmidt · Pull Request #2566 · opencloud-eu/web

dschmidt · 2026-05-20T10:47:51Z

⚠️ This PR explores feasibility. Nothing here is set in stone.
Function names, type names, extension point IDs, file layout, the shape of
the public surface, all of it is subject to change. DRY was explicitly not
an objective for this PoC, the goal was wiring the vault story end to end
to learn where the seams actually fall. Treat this as a proposal, not a
proposed merge.

Summary

Adds a folderVault extension type and the first implementation
(web-app-rclone-crypt) that surfaces rclone-crypt
compatible vaults in the OpenCloud Web UI under cleartext names. End users see
a *.vault folder, unlock it once per session via a passphrase, and read,
edit, upload and delete content as if it were unencrypted, all crypto happens
in the browser.

Plugin surface

FolderVaultExtension, pluggable filename/path/content (de)cryption engine
ResourceIndicatorExtension, pluggable per resource status indicators
in memory passphrase store (lost on reload, by design)
router level unlock guard mirroring the public link flow
empty vault create passphrase UX
lock vault / unlock vault context actions

Cross cutting integrations

Vault awareness wired into listing (loaderSpace), AppWrapper (load/save),
single file upload, drag drop directory tree upload, create file,
create folder, delete, SSE postprocessing, route guard.

Test coverage

Cucumber scenarios under tests/e2e/cucumber/features/rclone-crypt/ drive an
rclone CLI fixture to verify read, edit save, single file upload and drag
drop upload, all decrypt back to expected cleartext via the rclone CLI as a
ground truth oracle.

Notes

Known FIXMEs scattered:

content encrypt/decrypt buffers the entire payload before emitting
vault awareness lives in every caller rather than behind a single
decorator layer
hardcoded foobar is gone but the unlock flow could grow more checks

With the touch points now known, the right helpers and abstractions (likely a
webdav decorator or folder service decorator layer that absorbs the path /
content translation) will be evaluated next.

Introduces a `folderVault` extension type so apps can transparently encrypt and decrypt the names and contents of folders flagged as vaults, plus the first implementation (`web-app-rclone-crypt`) that surfaces rclone-crypt compatible vaults under cleartext names. Wires vault-awareness into listing, AppWrapper, single-file and drag-drop upload, create-file, create-folder and delete. Adds a runtime-level unlock guard that mirrors the public-link flow, an in-memory passphrase store, empty-vault create-passphrase UX and a lock-vault context action. Covered by cucumber e2e scenarios that drive an rclone CLI fixture.

Replaces the hand-rolled collectStream loops and single-emit ReadableStream wrappings in every vault encrypt/decrypt call site with two small helpers (streamToArrayBuffer, streamToBlob) plus Blob.stream() for input. The engine's streaming contract stays unchanged; only the call sites get tidier and the future "swap engine for real block streaming" lands without touching them.

- useResourceIndicators: tolerate test mocks that omit requestExtensions - useFileActions: silently bail in openEditor when no route exists (instead of filtering the action out, which broke route-null tests) - useFileActionsCreateNewFile: null-safe appFileExtension access - useFileActionsDeleteResources: drop the sync/async zalgo path, always return Promises; matching tests now await - web-test-helpers defaultComponentMocks: hasRoute defaults to true so the overwhelming majority of suites get the expected behaviour - web-app-preview: only opt out of preview service on explicit hasPreview() === false, preserve legacy behaviour for missing method - web-app-rclone-crypt: drop unused imports

…c DragEvent Headless Chrome silently swallows `new DragEvent(...).dispatchEvent(...)` fired from inside `page.evaluate`, so the drag-drop upload scenario worked headed and failed headless. Switching the helper to `locator.dispatchEvent('drop', { dataTransfer })` routes the event through CDP, where both modes behave the same way. dataTransfer is built in the page via `evaluateHandle(new DataTransfer())` so File objects and webkitRelativePath stay intact.

JammingBen · 2026-05-26T08:53:11Z

+  if (vaultEngine) {
+    for (const child of children) {
+      await decryptResourceInPlace(vaultEngine, child)
+    }
+  }


Can this happen in parallel? And I guess it should be done one the filtered newResources array below.

yeah, true! The api should handle a list, depending on the encryption implementation we can implement it much more efficiently that way

JammingBen · 2026-05-26T08:54:57Z

+        router.push({
+          name: 'files-spaces-generic',
+          params: { driveAliasAndItem },
+          query: resource.fileId ? { fileId: resource.fileId as string } : undefined


Suggested change

query: resource.fileId ? { fileId: resource.fileId as string } : undefined

query: resource.fileId ? { fileId: resource.fileId } : undefined

JammingBen · 2026-05-26T09:17:53Z

+// FIXME(poc-vault): this lookup currently lives next to the loaders and the
+// AppWrapper. Once we lift vault-aware translation onto a higher layer (e.g.
+// a webdav/client decorator or a folderService decorator), callers stop
+// needing to resolve the engine themselves.
+export function resolveFolderVault(


This only resolves unlocked vaults, right? Could you clarify this in the doc string?

JammingBen · 2026-05-26T09:22:24Z

+    handler: ({ resources }: FileActionOptions) => {
+      const resource = resources?.[0]
+      if (!resource || !isVaultRoot(resource)) return
+      const spaceId = resource.storageId as string


Suggested change

const spaceId = resource.storageId as string

const spaceId = resource.storageId

JammingBen · 2026-05-26T09:25:14Z

+    isVisible: ({ resources }: FileActionOptions) => {
+      const resource = resources?.[0]
+      if (!resource || !isVaultRoot(resource)) return false
+      return vaultStore.isUnlocked(resource.storageId as string, resource.path)


Suggested change

return vaultStore.isUnlocked(resource.storageId as string, resource.path)

return vaultStore.isUnlocked(resource.storageId, resource.path)

JammingBen · 2026-05-26T09:49:39Z

+  if (!password) {
+    return null
+  }
+  return createEngine(space.id as string, vaultRoot, password)


Suggested change

return createEngine(space.id as string, vaultRoot, password)

return createEngine(space.id, vaultRoot, password)

JammingBen · 2026-05-26T09:49:46Z

+    return null
+  }
+  const vaultStore = useFolderVaultStore()
+  const password = vaultStore.getSecret<string>(space.id as string, vaultRoot)


Suggested change

const password = vaultStore.getSecret<string>(space.id as string, vaultRoot)

const password = vaultStore.getSecret<string>(space.id, vaultRoot)

JammingBen · 2026-05-26T10:03:10Z

+        for (const child of children) {
+          await decryptResourceInPlace(vaultEngine, child)
+        }


Parallel possible?

JammingBen · 2026-05-26T10:08:34Z

+      // The editor's view may already be torn down by tiptap's own
+      // onBeforeUnmount hook by the time we run, depending on hook
+      // ordering. In that case `serialize` blows up reading a null schema.
+      // Flush the pending update if it's still safe, otherwise drop it —
+      // throwing here would break the rest of Vue's teardown.
+      const inst = editor.value as unknown as { view?: { state?: unknown } } | null
+      if (options.onUpdate && editor.value && inst?.view?.state) {
+        try {
+          options.onUpdate(strategy.serialize(editor.value))
+        } catch (e) {
+          console.warn('[useTextEditor] dropped pending update during destroy', e)
+        }


This has been fixed on current main meanwhile, I belive.

JammingBen · 2026-05-26T10:10:53Z

+          for (const child of resources) {
+            yield* call(decryptResourceInPlace(vaultEngine, child))
+          }


Parallel possible?

JammingBen · 2026-05-26T10:23:42Z

butonic · 2026-05-26T11:52:33Z

Can we split this into a part with the changes to web and move the rest into a dedicated extension?

dschmidt · 2026-05-26T11:54:21Z

Can we split this into the a part with the changes to web and move the rest into a dedicated extension?

We can, but I don't recommend it at this point. I would strongly suggest to keep it in web while it matures

dschmidt added 2 commits May 20, 2026 12:46

feat(rclone-crypt): add unlock-vault context action

cec7ee7

dschmidt added the Type:Enhancement label May 20, 2026

dschmidt added 4 commits May 20, 2026 12:58

test(rclone-crypt): rename readVault.feature to vault.feature

41daaf3

JammingBen reviewed May 26, 2026

View reviewed changes

	query: resource.fileId ? { fileId: resource.fileId as string } : undefined
	query: resource.fileId ? { fileId: resource.fileId } : undefined

	const spaceId = resource.storageId as string
	const spaceId = resource.storageId

	return vaultStore.isUnlocked(resource.storageId as string, resource.path)
	return vaultStore.isUnlocked(resource.storageId, resource.path)

	return createEngine(space.id as string, vaultRoot, password)
	return createEngine(space.id, vaultRoot, password)

	const password = vaultStore.getSecret<string>(space.id as string, vaultRoot)
	const password = vaultStore.getSecret<string>(space.id, vaultRoot)

Conversation

dschmidt commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Plugin surface

Cross cutting integrations

Test coverage

Notes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JammingBen commented May 26, 2026

Uh oh!

butonic commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dschmidt commented May 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dschmidt commented May 20, 2026 •

edited

Loading

butonic commented May 26, 2026 •

edited

Loading