It would be nice if this module would check view permissions for the content type the file is attached to (via filefield).

In my use case I have two different roles and two different content types. Each role has access to one of these types. However, both roles have access to all uploaded private files. So it would be nice if the files would additionaly be protected by the "view content type" permission.

Comments

johnhanley’s picture

johnhanley commented

This is an interesting request. However, does this assume the CCK "Content Permissions" module is enabled and the user has "view" permission for the particular field?

haggins’s picture

haggins commented

Good point. I don't know how ccks field permissions are implemented. But it should not be that hard to check if "Content Permissions" module is enabled and if it is, respect its permissons, too.

If a role has view access to a particular field but not to the content type the role is not able to see just this field at node/xy. So in this case the role shouldn't have access to a file even if access to the field is granted.

I think the hierarchy of permissions is as followed:

1. check private download permission
(check if file is associated with a field (if not return the file))
2. check view content type permission
3. check view field permission

johnhanley’s picture

johnhanley commented
Assigned: Unassigned » johnhanley

Yeah, I think your analysis is correct and this should be perfectly doable.

I have some professional and personal obligations that come first, but I will try and get to this within the next couple of weeks.

Thanks again for your suggestion.

John

ikeigenwijs’s picture

ikeigenwijs commented

This sounds ideal.
subscribe

johnhanley’s picture

johnhanley commented
Status: Active » Postponed (maintainer needs more info)

I was attempting to implement this idea today, but then became stumped on exactly how to determine the file-node relationship. It's easy when the user is accessing the node itself, but it's more difficult to ascertain the nid when the file is accessed directly. I'll need some constructive input before continuing to spend anymore time on it.

haggins’s picture

haggins commented
Status: Postponed (maintainer needs more info) » Active

For me it looks as the main problem is, that you don't know the fields name and according to that you also don't know the content type, do you? In that case searching for your fid <-> nid relationship over all {content_type_*} tables seems to be a solution.

Another one:
Catch all field names of type "filefield" out of {content_node_field} and filter for each filefield its table ( {content_%fieldname} ) for your fid (which is always in the column "%fieldname_fid").

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

It's been a while since this issue was started, but I'll share my code anyway :-)

I had to solve a similar problem today, so this is what I put in a custom module:

<?php
/**
 * Implements hook_private_download_access().
 * Deny access to a file if the user is not allowed to view any of the nodes
 * it's attached to.
 */
function mymodule_private_download_access($filepath) {
  // Find the node(s) to which this file is attached. 
  $prefix = file_directory_path() .'/'. variable_get('private_download_directory', 'private') .'/';
  $full_path = $prefix . $filepath;
  $file = field_file_load($full_path);
  $nodes = filefield_get_file_references($file);

  // Loop over nodes and check if the current user has access. Allow download if
  // we find a node which the user is allowed to view.
  foreach ($nodes as $nid => $vid) {
    $node = node_load($nid);
    if (node_access('view', $node)) {
      return TRUE;
    }
  }
  return FALSE;
}
?>

As you probably can see in the code, the file-node relationship as mentioned in #5 is determined by loading the file object and calling the filefield_get_file_references() function.

Hope this helps anyone - all feedback is welcome!

johnhanley’s picture

johnhanley commented
Assigned: johnhanley » Unassigned
Status: Active » Needs review

@marcvangend,

Thanks for sharing your code! I like the looks of it, very clean and efficient.

I'd curious to hear from the community whether this is a viable solution to the problem the OP presented and whether or not it makes sense to roll it into the Private Download and keep it as an external custom module if/when the needed arises.

All comments welcome.

Thanks,
John

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

Thanks for the feedback John. I'm curious to see what others think.

johnhanley’s picture

johnhanley commented
Issue summary: View changes
Status: Needs review » Closed (won't fix)

Closing due to Drupal 6 end-of-life cycle.