Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Managed files on a private file-system that do not have references from other entities can not be downloaded or viewed. Or styled using Drupal core's "image styles". This stems from lingering assumptions in Drupal 7 core that files are properties or meta data attached to other entities, instead of first class citizens (or entities) in their own right.
Specifically, this code in file_file_download() (an implementation of hook_file_download() in core's file.module) prevent access to the file. It was introduced in Drupal 7 in "#898036: Private images broken". And later extended to handle edge cases:
// Stop processing if there are no references in order to avoid returning
// headers for files controlled by other modules. Make an exception for
// temporary files where the host entity has not yet been saved (for example,
// an image preview on a node/add form) in which case, allow download by the
// file's owner.
if (empty($references) && ($file->status == FILE_STATUS_PERMANENT || $file->uid != $user->uid)) {
return;
}
Possible solutions
- Drupal core: Removing that code appears to solve the problem. And in brief testing I could not reproduce the original bug that #898036 intended to fix. I have not yet tried reproducing the bug or it's fix on Drupal 8, nor rolled a patch or run simpletests. While this is desirable, a core patch is a long-winded process which likely won't help Media module and File entity move forward at their current momentum.
- File Entity and/or Media module could implement it's own
hook_file_download()or create a dummy entity with references to all files just for this case. But neither of those are clean solutions. - File Lock module implements a solution for another bug resulting from Drupal 7's assumptions about Files, where files that have become "orphaned" are deleted, when any entity referencing the file is updated, created or deleted.
Conceptually, File Lock module should also solve the problem described here. However File Lock module solves the problem by adding a row to the
file_usagetable, whilefile_file_download()uses anEntityFieldQueryto look for entities that reference the file.File Lock module could be changed to handle both cases via a dummy entity. This is cleaner than doing so inside File Entity or Media modules.
- On that note, Drupal core's
file_file_download()could instead use thefile_usagetable which would be simpler, more performant and make it more extensible in cases like this. However that would also be a core patch and would still not help to fix Drupal core's broken assumptions about Files. - Any other ideas?
Similar: #1351906: Importing image fails on private file system..
#1351906 may be duplicate but the subject suggests that the import fails. While here the issue is downloading/viewing files that were successfully uploaded (or imported). I expect that the same issue will occur with imported images as they will also be "orphaned" as per Drupal 7 core's assumptions. I have not tested that case.
Also; I am not sure if the solution to this problem is best discussed in File Entity module's issue queue, or that of Media module, Drupal 7 or 8 core, possibly File Lock module's or a combination of the above. That probably depends on the solution(s) that are agreed to be most appropriate.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | eight.patch | 1003 bytes | Bevan |
Comments
Comment #1
gollyg CreditAttribution: gollyg commentedAt first blush, this doesn't seem to explicitly prevent access to the file, it merely says that it doesn't know what to do with it, as it is not being managed by the file/file field module. It would need to return -1 to prevent access.
Which seems in the spirit of hook_file_download. So wouldn't implementing this hook in file_entity make sense? Or even in modules that use file_entity (obviously media springs to mind), so that we aren't making assumptions about how the file is being managed.
More generally I agree that this is all a bit of a mess, and would love to see access control generalised out through an entity_access_api (usage is not a concept unique to files - any entity can reference any other entity, and an api to manage this would be great. eg http://drupal.org/node/777578
Comment #2
Bevan CreditAttribution: Bevan commentedThis patch fixes the bug by removing code that was added in #898036: Private images broken. And later extended to handle edge cases.
I tested both with current 8.x and 7.x git branches of Drupal core. And I tested each version both with and without the attached patch. The original bug reported in #898036 was not reproducible in any of the four scenarios. The bug described in this ticket was reproducible in both 7.x and 8.x without the patch, but was not reproducible with the patch.
The test method was not comprehensive but does make a good argument for removing the code that was introduce in #898036. Further review, testing and simpletests are required. The test method was;
Starting with a fresh "Standard" install;
admin/config/media/file-system: Configure a "Private file system path".admin/config/media/file-system: Make "Private local files served by Drupal." the "Default download method".admin/structure/types/manage/article/fields/field_image: Configure the "Upload destination" as "Private files".node/add/article: Set a title, upload an image file to the "Image" field and save the node.styles/large/private/from the image's URL and open the new shorter URL in a new tab (E.g. shift+enter in Chrome)field_data_field_imagethat corresponds to the recently uploaded file. E.g.DELETE FROM {field_data_field_image} WHERE entity_type = 'node' AND entity_id = 2where the node's NID is 2.styles/large/private/.Comment #3
Bevan CreditAttribution: Bevan commentedThe Drupal 7 issue for this bug is #1420812: Files from private stream cannot be downloaded.
Comment #5
Bevan CreditAttribution: Bevan commentedThe test that failed was "Confirmed that access is denied for the file without the needed permission." (
FilePrivateTestCase->testPrivateFile()).That failed because this change makes all files always accessible. The code that the patch removes is keeps private files private, without explicitly denying access to them. This bug is more complicated and raises bigger questions about how file access permissions should be managed.
Comment #6
Bevan CreditAttribution: Bevan commentedA related bug with private file systems that applies to files on taxonomy terms is #1423750: Private files on Taxonomy Term fields are not displayed.
Comment #6.0
Bevan CreditAttribution: Bevan commentedAdding tags around the File Lock solution to make it more consistent and more detail about the alternate Drupal core solution.
Comment #7
andros CreditAttribution: andros commentedUsing D7 I have noticed I can't access any file that is not some how connected to a node,
this means:
If private file system is set as default:
and
I have searched for this for some time now. Is there relay no solution for this?
I have tested this on different Servers, with different installations and with fresh installs, allays the same.
Meaning: Drupal comes with a broken private file system?
Comment #8
deanflory CreditAttribution: deanflory commentedAndros, I too can't access sample images from the Image Styles previews and I'm using a private file system. I can however see the logo of the them and default images on fields. I too am amazed this hasn't been fixed yet. Everybody is too busy working on Drupal 8 and has almost completely neglected Drupal 7. At least with D6 enough module maintainers kept up their modules, not really the case for the majority in D7.
</gripe>Comment #9
Bevan CreditAttribution: Bevan commentedAndros; yes
Comment #13
meezaan CreditAttribution: meezaan commentedHas there been any update on this issue?