Private file without relying on the obsolete upload module [#1559608]

A client requires that the files attached to a protected node must be protected (which is what I expected). I've found that the current code use the upload module to check permission on a file. The module being obsolete I've quickly searched for a way do the same with drupal 7 core only.

Files attached from a field are added to a managed_files table which makes it possible to get a file object from a filename. Then there is also a new function file_usage_list() which does exactly what it tells, find all places where a file is used.

Now I've reworked a little the logic inside the protected_node_and_attachment() function. Since a file can be attached to multiple nodes I decided to do the access verifications on all nodes. This means that if a node is unprotected, all files attached to it will get unprotected too. This is not the most restricting way to handle this but I feel it's the only logical one.

In the following patch I've commented a part of the function that checked if other modules implemented a "file_download" callback. It was making impossible to protect files even if I had no special access control modules. Any suggestion about this part?

Comment	File	Size	Author
#6	private_file-1559608-6.patch	2.9 KB	stockliasteroid
#6
#3	private_file-1559608-3.patch	4.53 KB	idflood
#3
#2	private_file-1559608-2.patch	4.44 KB	idflood
#2
#1	private_file-1559608-1.patch	4.46 KB	idflood
#1

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

idflood CreditAttribution: idflood commented 3 May 2012 at 16:53

Status:

Active

» Needs review

File	Size
private_file-1559608-1.patch	4.46 KB

Comment #2

idflood CreditAttribution: idflood commented 4 May 2012 at 14:21

File	Size
private_file-1559608-2.patch	4.44 KB

Same patch as in #1 but without trailing whitespaces.

Comment #3

idflood CreditAttribution: idflood commented 4 May 2012 at 15:02

File	Size
private_file-1559608-3.patch	4.53 KB

New patch: if a node type isn't protected then the files associated to one of it's node will not be protected (even if also associated to one protected node).

Here is the little added condition

|| isset($node->protected_node_is_protected) == FALSE // "never protected" node type

Comment #4

Sakrecoer CreditAttribution: Sakrecoer commented 15 June 2012 at 18:24

I am not sure if i understand you right. So pardon me if i'm double posting....
Having this said: Even thou my file is Private, when attached to a protected node, it is still possible to download the file without having to enter a password.

PS. GREAT WORK THOUGHT!!! I love it! Been longing for a module like this one for quite sometime (simply didn't find it until today...) !!!!! And i'm not dealing with CIA secrets nor super fancy pricless files, so this bug is not a "mjaor problem" for me... Bravo!

Comment #5

parasolx CreditAttribution: parasolx commented 28 November 2012 at 16:21

I'm applied this patch to current dev version.

Set file field to private upload. Access to content given after enter correct password. But when click to download private files, it shows Access denied even to administer user (uid=1).

Comment #6

stockliasteroid CreditAttribution: stockliasteroid commented 4 December 2012 at 01:08

File	Size
private_file-1559608-6.patch	2.9 KB

I took a different approach here... I couldn't get the above patches to apply to latest -dev, and it seems like the more appropriate thing to do is to update the implementation of hook_file_download. Drupal uses this to determine if a user should have access to a given private file uri, which in my case was a PDF attached via a File field.

file_usage makes it possible to find nodes that use the file uri passed to hook_file_download, so I check each of the nids where the file is used to see if the user has any of those nids in their list of allowed nodes. If so, then allow the file to be downloaded. This means that if a user has access to a file on one protected node and that file is re-used on another node the user DOES NOT have access to, they would still have access to that file due to it's association with the first accessible node. That seems reasonable to me, but I suppose it could potentially be an issue for some.

Let me know if it works... It seems to work fine on my end. Thanks!

Comment #7

bensey CreditAttribution: bensey commented 9 August 2013 at 03:38

This patch from #6 worked well for me.
It successfully delivers a 403 for private files if the user hasn't entered the password in the protected node.

Thanks stockliasteroid! Nice one!