fix(handlers): offer encrypted files only to handlers that read them over dav - #38
Merged
Merged
Conversation
…over dav Since Nextcloud 33 the end-to-end encryption app decrypts files transparently, but only on the WebDAV endpoint. A handler that fetches the bytes through an endpoint of its own gets ciphertext, so the old viewer app limited encrypted files to its image, video and audio handlers by mime (nextcloud/viewer@5aeb510e). This library did not carry that over and offered an encrypted file to every handler taking its mime. A handler now opts in with supportsEndToEndEncryption, set on the three default handlers, and a set holding an encrypted file is never shown to a handler without it: not through the file actions, not through canView(), and not by the viewer picking a handler for a file in the list. The handler's own enabled() is not even asked. Assisted-by: ClaudeCode:claude-opus-5 Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
skjnldsv
added
status: review
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #38 +/- ##
==========================================
+ Coverage 87.83% 87.86% +0.03%
==========================================
Files 36 36
Lines 2474 2481 +7
Branches 519 521 +2
==========================================
+ Hits 2173 2180 +7
Misses 297 297
Partials 4 4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
Author
|
@artonge does it make sense? |
artonge
approved these changes
Sep 16, 2026
artonge
left a comment
artonge
left a comment
There was a problem hiding this comment.
I would prefere that we support the other ways of fetching files, but that is not hapening anytime soon. So good enough for now :).
Previews of end-to-end encrypted files are not a given, so the docs no longer name them as a way to read one: the flag is about reading the file from its dav source. Assisted-by: ClaudeCode:claude-opus-5 Signed-off-by: skjnldsv <skjnldsv@protonmail.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The old viewer app grew this after the library forked from it: nextcloud/viewer@5aeb510e limits end-to-end encrypted files to the image, video and audio mimes, because since Nextcloud 33 the e2ee app decrypts transparently, but only over WebDAV. A handler fetching through its own endpoint (Text, the PDF viewer) gets ciphertext. The library offered an encrypted file to any handler taking its mime.
Rather than a mime list in the core, the handler says so:
supportsEndToEndEncryption?: booleanonIHandler, set on the three default handlers.isHandlerEnabled()refuses a set holding a file with thee2ee-is-encrypteddav attribute for a handler without the flag, before asking itsenabled(). That one function is behind the file actions,canView(),getHandlerForFile()and the viewer's ownhandlerFor(), so all four agree.Handlers that read the file from
node.encodedSourcecan set the flag. It is additive, the default is the safe one, and the README table and example carry it.__tests__/encryptedFiles.spec.ts: refused without askingenabled(), taken with the flag, one encrypted file taints a set,falseor absent attribute changes nothing,canViewandgetHandlerForFileskip to the flagged handler, "Open with" entries follow, and the three defaults carry the flag. Not tested against a live e2ee setup.👾 This pull request was assisted by Claude Code, commits carry an
Assisted-bytrailer.