ZNikke
commented
1 year ago 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.
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: https://github.com/dCache/dcache-view/issues/269 Fixes: https://github.com/dCache/dcache-view/issues/268