Access Denied on file attachment when node state is Draft in Workbench

Question

I have a file attachment field defined in a content type I have under Workbench moderation. The file field stores the attachment in the private files folder.

PROBLEM:

When I create a node for that content type and view it in Draft mode I get a 403 access denied if I try to download the file attachment with any role other than admin. If I publish the node I can download the file fine. Revert it back to Draft and I'm back to the 403 access denied.

I've tried enabling “Bypass moderation restrictions” for a role but that does not work around this error.

I really need a solution/workaround for this issue since I have a non-admin role that needs to be able review the node and the file attachment posted by users before they are published. I'm sure this is a fairly common scenario but I haven't been able to find any posts with a similar issue.

Answer 1

When using the private file system file_file_download() only checks access for files attached to the current revision of an entity (via file_get_file_references()).

This is to stop users who have access to view the node from viewing files attached to old revisions (that might contain out of date files), and other similar things.

If there are no current revisions that contain that file it returns NULL, which then in file_download() means that get access denied.

See a related drupal core issue: https://drupal.org/node/1453138
The D8 version of that issue is: https://www.drupal.org/node/1452100

In theory, you should be able to implement a hook_file_download() that checks all revisions by essentially copying file_file_download, but making file_get_file_references() return for all revisions.

The problem with that solution is it can introduce a security hole, which is that users who have access to view the published version of the node can also now view files attached to other revisions of the node, which depending on your use case may or may not be an issue but since you are using the private file system in the first place I assume it might be a problem.

To avoid that, you could then implement hook_file_download_access(), which does more complex access control than just calling node_access() like the node_file_download_access() function does. In that hook you would want current revisions to run through node_access() and non-current revisions to use extra access control, like checking the users workbench permissions or node creation/editing permissions.