Thanks for a great module, but I am having some serious issues with this module:
When I deny access to 'view filefield uploads' to a user role (eg. anonymous users), then filefield also affects img_assist and even normal file attachments for the same role. That is, I cannot view images or download other file uploads from this user role. This is happening when using 'private' filesystem download method. I think this is a bug that should be examined closely.

Thanks

Konstantinos

Comments

jpetso’s picture

Just to not leave this issue out in the cold: yes, that's a major bug, and rightly set critical. Currently, the download hook needs to be implemented by filefield because the upload module (which provides the original hook, only with 'view uploaded files' permission) might not be active. The download hook is a straight copy of upload_file_download(), and only changes the required permission. Guess that when upload.module is enabled as well, any of the two hooks indicating a denial cause the file to be denied.

Maybe a good idea would be to check on both the filefield and the upload.module permission... but then again, the "just drop access rights" approach that was proposed in issue #191333 would also be a possible way to go. Neither of these are hard to implement, but I don't know which one to take. Please let me talk this through with some knowledgable people.

dopry’s picture

You should allow access for all.. I'm not going to try to play nice with upload's permissions. Blame hook_file_download and work on a new implementation if you don't like it. I can't depends on upload.module being installed and I'm not longer going to support filefield and upload.module together, due to the mutual exclusion in the permissions. Until core get hook_file_download right... this wont' be fixed.

kmargar’s picture

Status: Active » Postponed

Then postpone the bug, 'won't fix' is bad manners, it's a bug, no matter whose fault it is. This should be left open, closing a bug just because you don't like it isn't the way open source works. I'll try to look this closer but I'm not *that* knowledgable about drupal's internals.

Thanks

Konstantinos

dopry’s picture

Status: Postponed » Closed (won't fix)

@codex.gr: This is an issue I won't fix. There is other work focused on improving file access control for core. As far as filefield is concerned this issue is 'won't fix'. That's my position as the project maintainer. Energy should be focused on fixing the root of the problem, not wrapping duct tape around it in contrib modules.

.darrel.

tomski’s picture

Hello,

I have got a problem related to this and solved with pure bricolage since I have no knoweledge at all of php.

The problem: by setting filefield permissions to prevent anonymous access I blocked also the access to all the images managed through the image.module. While the files uploaded through the upload.module were still accessible. I guess the reason why is that filefield blocks the access to any field with a file uploaded to (but this is really a guess).

The solution: so I had a look to the code of the module, and came up with this by trial and error :

// @todo: check the node for this file to be referenced in a field
// to determine if it is managed by filefield. and do the access denied part here.

if (!user_access('view filefield uploads') && ($field_name == 'private')) {
// sorry you do not have the proper permissions to view
// filefield uploads.
return -1;
}

Which basically limited the control access of filefield to the only field 'private', and that was what I needed. And it works.

I posted this for two reasons:
1) In the case someone has the same problem it can be a solution.
2) Why those who know php could not tell FileField to apply access control only to the fields that FileField has actually created? (which I believe is somehow implied by the "todo" note in the code).

Thanks for this very useful module!

nicksanta’s picture

Status: Closed (won't fix) » Active

Hi, I've come across this issue myself. Basically, I have a 'software release' node, which has a custom node access module blocking access to the public. It also has a filefield which i use to upload the software itself, and have an custom file access module to control downloading of it using the private download method.

My problem has been, because the node itself is blocked from the public, the file has been as well. This would be expected behavior in 99% of cases, and I respect that. I do however, have a lightweight solution that allows custom modules and sites to bypass this restriction.

This is in filefield.module, around line 122

<?php
/**
 * Implementation of hook_file_download().
 */
function filefield_file_download($file) {
  $file = file_create_path($file);

  $result = db_query("SELECT * FROM {files} WHERE filepath = '%s'", $file);
  if (!$file = db_fetch_object($result) || variable_get('filefield_bypass_access', FALSE)) {
    // We don't really care about this file.
    return;
  }
?>

As you can see, I've simple added in || variable_get('filefield_bypass_access', FALSE) to the top of this function.

Then, all i have to do in my settings.php file is add this:

<?php
// The filefield module enforces node access checking on files stored using it, the bypasses it's hook so
// we can control it ourselves
$conf['filefield_bypass_access'] = TRUE;
?>

Modules could also bypass this by using hook_enable & hook_disable

Anyway, sorry for reopening a dinosaur, especially a won't fix, but i think this is a solution which doesn't really have any downsides, but makes the module more versatile.

nicksanta’s picture

Version: 5.x-2.2 » 6.x-3.2
Category: bug » feature

Whoops, should also make this relevant to latest version

quicksketch’s picture

Status: Active » Closed (won't fix)

Back to won't fix, unless you can get this change into D7 first.