Closed (won't fix)
Project:
FileField
Version:
6.x-3.2
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
28 Oct 2007 at 18:46 UTC
Updated:
30 Jun 2010 at 01:59 UTC
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
Comment #1
jpetso commentedJust 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.
Comment #2
dopry commentedYou 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.
Comment #3
kmargar commentedThen 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
Comment #4
dopry commented@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.
Comment #5
tomski commentedHello,
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!
Comment #6
nicksanta commentedHi, 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
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:
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.
Comment #7
nicksanta commentedWhoops, should also make this relevant to latest version
Comment #8
quicksketchBack to won't fix, unless you can get this change into D7 first.