Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle encryption state in web interface #6670

Merged
merged 4 commits into from
Dec 6, 2017

Conversation

schiessle
Copy link
Member

@schiessle schiessle commented Sep 27, 2017

  • add a nice looking lock in front of a end-to-end encrypted folder
  • handle permissions correctly
  • hide '...' menu for encrypted folders

The easiest way to review is by setting "encrypted" in the filecache table to "1" for a folder and check if all the file actions are gone.

@schiessle
Copy link
Member Author

@nextcloud/javascript could need some help from our Java Script experts to hide the complete "..." menu for end-to-end encrypted folders.

@codecov
Copy link

codecov bot commented Sep 29, 2017

Codecov Report

Merging #6670 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #6670      +/-   ##
============================================
+ Coverage     50.84%   50.85%   +<.01%     
  Complexity    24547    24547              
============================================
  Files          1585     1585              
  Lines         93801    93812      +11     
  Branches       1354     1357       +3     
============================================
+ Hits          47697    47709      +12     
+ Misses        46104    46103       -1
Impacted Files Coverage Δ Complexity Δ
core/js/mimetypelist.js 100% <ø> (ø) 0 <0> (ø) ⬇️
core/js/mimetype.js 91.48% <100%> (+0.37%) 0 <0> (ø) ⬇️
core/js/share.js 43.15% <100%> (+1.22%) 0 <0> (ø) ⬇️
core/js/files/client.js 84.89% <100%> (+0.23%) 0 <0> (ø) ⬇️
lib/private/Server.php 83.19% <0%> (-0.12%) 126% <0%> (ø)
apps/files_trashbin/lib/Trashbin.php 72.53% <0%> (+0.24%) 136% <0%> (ø) ⬇️
lib/private/Security/CertificateManager.php 92.07% <0%> (+0.99%) 39% <0%> (ø) ⬇️

@schiessle schiessle added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Sep 29, 2017
@schiessle schiessle force-pushed the handle-encryption-state-in-web-interface branch from 3f5e1aa to 81b9363 Compare September 29, 2017 15:35
Copy link
Member

@danxuliu danxuliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -370,6 +370,9 @@
_renderMenuTrigger: function($tr, context) {
// remove previous
$tr.find('.action-menu').remove();
var isE2EEncrypted = $tr.data('e2eencrypted');

if (isE2EEncrypted) return;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the most common style in our JavaScript code is

if (isE2EEncrypted) {
    return;
}

@@ -304,6 +309,13 @@
data.hasPreview = true;
}

var isEncryptedProp = props['{' + Client.NS_NEXTCLOUD + '}is-encrypted'];
if (!_.isUndefined(isEncryptedProp)) {
data.isEncrypted = isEncryptedProp === '1';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be sure, the server is guaranteed to always return '1', never 1, true or 'true', right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that's what's stored in the file cache table

@@ -108,6 +108,7 @@ OC.MimeTypeList={
"folder-public",
"folder-shared",
"folder-starred",
"folder-encrypted",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please amend to keep the alphabetical order :-)

@schiessle schiessle force-pushed the handle-encryption-state-in-web-interface branch from 81b9363 to f7fa1cd Compare October 10, 2017 09:39
@schiessle
Copy link
Member Author

@danxuliu thanks for the review... I fixed the small stuff. May I ask you to have a look at the test? This would be awesome because I'm really bad with JS tests... Thanks a lot!

@icewind1991
Copy link
Member

  • I can still enter an encrypted folder

  • Share icon should stay aligned when the dots aren't there

    image

Code looks good otherwise

@danxuliu
Copy link
Member

@schiessle

May I ask you to have a look at the test?

No problem :-) I will need some clarification on the expected behaviour, though. What actions should be available on encrypted folders? And why are those actions available and not others?

I have also realized that just not rendering the three dots button is not a proper solution. Right now an encrypted folder can be favourited by clicking on the star icon on the left. However, once the checkbox is placed where the favourite icon is now, the favourite action would be shown inside the three-dots menu, so the three-dots icon should be shown even for encrypted folders, although only with a single action.

So, in the same way that file actions are currently filtered based on permissions and mime types, an option could be to filter all actions on encrypted folders except those marked as allowed-on-encrypted (or something like that). I could implement that if needed... although probably not in the next days, sorry :-S

@icewind1991

I can still enter an encrypted folder

If you should not enter an encrypted folder I would expect the server to prevent that. Otherwise, even if fixed in the web UI, you could simply replicate the current web UI behaviour "manually" and get access to the folder. Maybe the server does not prevent it because there is no proper encryption in place and it would not allow that on a real case (assuming that you just used the trick of setting encrypted to 1 in the filecache table, but I do not know if that is what you did :-) )?

In any case, what should be the expected behaviour? Not allowing to click on the folder? Showing a warning/error saying that it is encrypted and that it can not be accessed? Showing a dialog that ask for a decryption key to be able to enter?

Share icon should stay aligned when the dots aren't there

If the filtering I described above is implemented I think that the alignment should be fixed in a different pull request, as it could be seen as a general case of "When there are no actions to be shown in the file actions menu the file actions trigger should not be shown, and the in-line actions should be kept aligned" (although that would not happen anyway once the pull request to change the placement of the checkbox is merged, so... I would say that this has low priority).

@danxuliu danxuliu added 2. developing Work in progress and removed 3. to review Waiting for reviews labels Oct 14, 2017
@schiessle
Copy link
Member Author

schiessle commented Oct 17, 2017

@icewind1991 did you enabled the end2end encryption app on the server? If it is enabled access to the folder should be blocked

The share icon shouldn't be there at all, at least it isn't for me, again the e2e app needs to be enabled

@schiessle
Copy link
Member Author

schiessle commented Oct 17, 2017

@danxuliu thanks a lot for the js tests! All operations on the encrypted folders should be removed. At the moment just the option to "star" the folder is still there which is fine.

As said to @icewind1991, in order to block access to the folder you need to have the "end to end encryption" app enabled. This contain a sabre dav plugin which blocks all the operations.

@schiessle schiessle force-pushed the handle-encryption-state-in-web-interface branch from d55a7a7 to efa876b Compare October 26, 2017 11:55
@danxuliu
Copy link
Member

I have realized that there is no need to add another field to file actions to specify whether they are allowed on encrypted folders or not to filter the file actions by that field as I initially thought.

When installed in the server, the E2E encryption app blocks all the permissions in responses to PROPFIND requests, and file actions are currently filtered based on the permissions they need and the permissions that the user has on the file. For example, the download action needs read permissions, while the move action needs update permissions. Therefore, as encrypted files have no permissions (in the web UI) everything should simply work.

But it does not :-P The reason is that the JavaScript files client sets the read permission on all files, no matter the permissions returned by the server. Thus all the actions that need read permissions are enabled for encrypted files even it they should not.

Besides that, currently every action require a permission, even if they should not. For example the favorite action requires the read permission, but there is no need to be able to read the file to mark or unmark it as a favourite. That is probably due to the read permission being always on and the fact that some code that works with file permissions currently does not work as expected if the actions requires no permissions (as it would filter out the action even if it should not).

Finally, when selecting several files on the file list the delete action is hidden if any of the files can not be deleted. However, the Move or copy and the Download actions are always shown even if some of the selected files do not support that action.

With all of the above my proposed solution would be to fix the handling of permissions in the file list and then handle encrypted files just like any other file, as the available actions will be automatically adjusted based on the permissions of encrypted files. Does this sound sane?

@schiessle
Copy link
Member Author

@danxuliu yes, the webdav plugin sets already the permission to '0' if you can make the javascript to keep this, this would probably work.

@danxuliu
Copy link
Member

danxuliu commented Nov 2, 2017

I have rewritten the commit history to squash the unit tests to their related commits, extract the fixing of whitespace errors to its own commit, remove the commit that hid the three dots menu (as the Favorite and Details action could be performed on encrypted folders), and add some missing details (setting the folder icon too on markFileAsShared).

This pull request now requires #7046 and #7047 to be merged first; this pull request should be rebased on master once that happens, as there are some minor conflicts.

Also note that there is still a bug in this code: when the Share tab is shown the file row loses part of its metadata, and if the Share tab is loaded again (if it is simply opened there is no problem) then the encrypted folder will appear as a regular folder. For reference, the problem happens when updating the file info model due to the sharesChanged event being triggered, but I have not found the cause yet :-(

@schiessle
Copy link
Member Author

@danxuliu all dependencies are now merged, can you rebase this PR and take care of the merge conflicts? Thanks!

schiessle and others added 4 commits November 20, 2017 18:24
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
@danxuliu danxuliu force-pushed the handle-encryption-state-in-web-interface branch from 57c85eb to 7bc28f1 Compare November 20, 2017 20:03
@danxuliu danxuliu added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Nov 20, 2017
@danxuliu
Copy link
Member

@danxuliu all dependencies are now merged, can you rebase this PR and take care of the merge conflicts? Thanks!

Done ;-)

I have also fixed the bug mentioned in my last comment; it was caused by elementToFile not setting the isEncrypted attribute.

When rebasing onto current master I dropped the commit that fixed the whitespace errors (they are now fixed in master) and split the commit to show the E2E folder icon in two, one to add the e2eencrypted attribute to the file list rows and another one just to show the E2E folder icon.

This pull request is now ready to be reviewed! :-)

@schiessle
Copy link
Member Author

@danxuliu great. I will try it out! 😃

@schiessle
Copy link
Member Author

tested it and it works really great! Thanks @danxuliu

@nickvergessen @icewind1991 @rullzer can you please review it? Thanks!

Copy link
Member

@LukasReschke LukasReschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐘

@tobiasKaminsky tobiasKaminsky merged commit 430f60d into master Dec 6, 2017
@tobiasKaminsky tobiasKaminsky deleted the handle-encryption-state-in-web-interface branch December 6, 2017 15:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants