Let browser handle downloads directly and support multi-file download #294
Conversation
This file contains 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
|
Ugh, discovered that I confused myself when testing to think that it worked in the shared-files view. It doesn't, in the sense that the shared-files view uses another code path with similar functionality as the main one and thus still has the old behavior. I'll look into making this code be used there as well, to match the pull request description. |
ZNikke
force-pushed
the
let-browser-download
branch
from
757a1fb to
bb332f3
Compare
ZNikke
changed the title
|
There, I think this works as intended now. |
Currently dCacheView handles downloads by first doing the download and only when the download has completed it passes the object along for the browser to handle. The result is no feedback at all for users when initiating download of large files since the save dialog is shown on completion, and huge files might not download at all if the temporary browser download location runs out of space. Work around this by letting the browser handle the download instead, the method chosen is to create a temporary Anchor element to drive the download action as it has an explicit download attribute and avoids issues with modern browser pop-up blockers. Since username/password (Basic) auth can't be reliably passed along a short-lived Macaroon is created to handle the download. Existing Macaroons are used as-is to handle download in the shared-files top-level view. Sessions with certificate authentication are assumed to work as-is, bypassing the Macaroon generation stage. The result is a decent end user experience when downloading files, including huge files that are common in a scientific data store. Missing in this patch is handling of subdirectories in the shared-files view. Credits go to various threads on https://stackoverflow.com/ for explaining numerous corner cases and nuances in this area. Fixes: dCache#269 Signed-off-by: Niklas Edmundsson <[email protected]>
dCacheView is limited to file-by-file downloads, which is frustrating users since there is support for multi-file selection. This patch builds on the previous one to enable downloads for multi-file selections. The simplest solution is implemented that triggers multiple file downloads in the browser, this is also found to work best with tablets and smartphones, where the traditional method by handling multi-file download by providing a .zip archive of the files is really cumbersome to handle. There is also a completion of the implementation to handle sub-directories in the shared-files view. The end result is that it is now possible to select multiple files in a directory and then download them in a smooth manner. Fixes: dCache#268 Signed-off-by: Niklas Edmundsson <[email protected]>
ZNikke
force-pushed
the
let-browser-download
branch
from
bb332f3 to
17161f8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Currently dCacheView handles downloads by first doing the download and only when the download has completed it passes the object along for the browser to handle. The result is no feedback at all for users when initiating download of large files since the save dialog is shown on completion, and huge files might not download at all if the temporary browser download location runs out of space. Further frustrating users, you can select multiple files but is not allowed to select download.
Work around this by letting the browser handle the download instead, the method chosen is to create a temporary Anchor element to drive the download action as it has an explicit download attribute and avoids issues with modern browser pop-up blockers. Since username/password (Basic) auth can't be reliably passed along a short-lived Macaroon is created to handle the download. Existing Macaroons are used as-is to handle download in the shared-files view. Sessions with certificate authentication are assumed to work as-is, bypassing the Macaroon generation stage. The same basic mechanism is used to allow download of multiple files, this is also found to be easier to use on tablets/smartphones compared to the common .zip archive solution.
The result is a decent end user experience when downloading files, including multiple huge files that are common in a scientific data store.
Credits go to various threads on https://stackoverflow.com/ for explaining numerous corner cases and nuances in this area.
Fixes: #269
Fixes: #268