FileEntityAccessControlHandler groups together download, update & delete operations together; this breaks core Drupal download functionality.
Accessing Private Files
It is important to understand that just because a file field is configured to use the private file system, that does not mean Drupal will prevent anyone from viewing files uploaded via that field. The files will be served by Drupal (via a URL like "/system/files/name-of-the-file.pdf"), but Drupal will only block users' access to download the file via that URL if there is a specific reason to do so.
For example: you have created a new content type with a file field which stores files in your site's private file directory. Next you create a node from this new content type and attach two new files. When the node is published links to both attached files are visible and anyone who can view the node may download the files. Now, if you unpublish the node so that your site's end users can no longer access it, all attached files become inaccessible for download by those users also, even if they use the direct link to the files that worked when the node was published.
https://www.drupal.org/docs/8/core/modules/file/overview#content-accessi...
File Entity already falls back to the core File module for upload access check, the interim solution is to also fall back for the download access check, this will at least allow the site I am currently working on to use the function.
file_entity_file_download() in also conflicts with FileEntityAccessControlHandler, file_entity_file_download() uses the 'view' operation and FileEntityAccessControlHandler uses the download operation. #2799897 removes the check on view access in file_entity_file_download().
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2892628-n6.patch | 2.01 KB | hanoii |
Comments
Comment #2
dwkitchen commentedThis patch falls back to core access check for download operation.
Comment #3
matt_paz commentedAnother potentially related issue could be ...
https://drupal.stackexchange.com/questions/244263
Comment #4
David_Rothstein commentedAdding a related issue that links to this one, and marking "needs review" since there is a patch.
Comment #5
joseph.olstadFYI , for D8 , the file_entity tests currently only pass on core 8.3.x , so if you want a baseline pass, trigger the tests vs 8.3.x
someone will have to open a related issue for the 8.4.x and 8.5.x tests if not already done so. ( I think there is already an issue open for that , but please do check)
Comment #6
hanoiiFollow up from #2799897-13: Simplify file_entity_file_download?.
I am unsure if this is a bug of is a by-design issue, it's unclear but I do agree with the above in which for downloads access, the parent file access control should be referenced as it has a nice addition unless this module's taking over permissions completely is really wanted, which in this case, there should be a way to use the parent logic too.
It's very useful for things like matching the file access to the entity view access. One should be able to download the file if the user is able to see the host entity and field.
So this patch, while adding a bit of readability does a very similar thing to the above but keeps this module's permissions. If enabled it will take precedence for those roles.