Add support for files with no permissions #7047
Conversation
Until now it was safe to assume that every file was readable by its owner, so there was no need to return whether the file was readable or not. However, with the introduction of end to end encryption that is no longer the case, and it is now necessary to explicitly provide that information. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now a file gets its directory permissions only if it contained no permissions (they were undefined or null), but not if its permissions were set to "NONE". Besides that, now file actions that do not require any permission on the file to be performed can be used on files that have no permissions. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The Details and the Favorite actions do not require any permission on the files to be performed. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The first parameter of "apply" must be the object to act as "this", and the Promise callback gets the parameters provided in the "resolve". Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that these tests are executed they are revealed to be partially obsolete; they were fixed to match the current parsing behaviour. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that the permissions returned by the server specify whether a file is readable or not the frontend no longer needs to assume that every file is readable. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
force-pushed
the
add-support-for-files-with-no-permissions
branch
from
ddb7217
to
3e844d3
Compare
Codecov Report
@@ Coverage Diff @@
## master #7047 +/- ##
============================================
+ Coverage 50.61% 50.62% +<.01%
- Complexity 24297 24298 +1
============================================
Files 1577 1577
Lines 92922 92926 +4
Branches 1359 1359
============================================
+ Hits 47036 47045 +9
+ Misses 45886 45881 -5
|
danxuliu
added
3. to review
|
I'd love to have some thoughts of @icewind1991 or/and @rullzer on this. Is this the best approach? Or should we have a dedicated flag for the E2E? :) |
|
Mmmm I'm not sure this is right. Because the file is still readable by the owner. It is just encrypted. If I'm not mistaken the folder that is encrypted has the encrypted flag set. @schiessle So the js should check for that... |
It is not readable, at least not from the point of view of the web UI (or any other insecure client). When installed in the server, the E2E encryption app blocks all the permissions in responses to But encryption aside this pull request simply makes the readable permission more consistent with the other permissions; the other permissions are explicitly returned by the server if they are set for a file, but readable was never returned and the web UI simply assumed that it was always set. Now the server explicitly returns the readable permission if it is set for a file and the web UI honours the returned permissions.
The reason to use the permissions instead of the encrypted flag was to avoid introducing specific cases and to use the general code instead (after the needed fixes, I mean ;-) ). |
|
Ok so if the app actually sets the permissions to non readable for files. Then yes lets just properly display this. |
|
@rullzer is this a +1? |
Until now it was safe to assume that every file was readable by its owner, but with the introduction of end to end encryption that is no longer the case. Therefore, the server now must explicitly return whether a file is readable or not, and the web UI has to be prepared to handle files with no permissions (which is simply a matter of fixing some code that assumed that the file would always have at least the read permission).
This is a requisite for proper handling of encrypted folders in #6670.