File field permission only hides the file and doesn't deny download in private file system

I agree that it would be great if field permission could control if the file could be downloaded or not. But if it could it should not be related to if the field is visible or not , it would be better to have a new permission called download filed content or something. On the other hand that permission would only be related to file/image fields and not others, which makes the module more complex.

If i not wrong, drupal 6 if you can't view the field it can't be download or access the field. I moving to drupal 7 and hang here cause i need role control view and download option. Anyone patch?

I using nginx so can block folder access to file directly and must go thru drupal. see http://groups.drupal.org/node/158059 and those using apache should have a permission setting on the folder itself.

I can confirm that problem – had to solve the issue with another module/hack.
If a user isn't allowed to view the file field he shouldn't able to download from a private file space (for public files that's not possible, that's ok). Some work is needed I think.

Subscribe

Fixing title.

Subscribe

Can you explain what you did to get it working?

Can you explain what you did to get it working?

bump, i want that, too

I unpublished this issue for a while, because it turned out to be due to a security problem in Drupal core.

That bug is now fixed (see http://drupal.org/node/1425084), so as long as you are using Drupal 7.11 core or higher, this should no longer occur.

I am running on 7.29 core and field_permissions 7.x-1.0-beta2 and this issue seems to still be there. Is it a come back?

I'm running into this as well.

I'm using private a private file system path and serving these private files only through Drupal.

However, this module ignores those settings and allows files to be served by apache to anyone with a URL for a private file.

It's a neat trick, but I do think this is a bug (and potentially a dangerous one).

Worth noting: setting the custom permissions for the field will limit access to anonymous users.

I can't replicate this on Drupal 7.34 with field_permission 7.x-1.0-beta2. Spun up a site on simplytest.me and the field permissions were respected when trying to download the actual image.

Hi LGLC,

Did you set up the path for Private File system and set the default download method to serve private files through drupal?

I just set up a test on simplytest.me with the D7 and field_permission beta2.

I have the image field's upload destination set to "private" (for the article content type).

When i create a node, the image's url is being served from a private file path like this:

http://s137c1aab8673650.s3.simplytest.me/system/files/styles/large/private/field/image/1.jpg?itok=bBEaic65

However, I can access this image without being logged in to the site, which defeats the purpose of using a private file system.

Thanks for you time.

@ydahi Ah, I've just seen your 'worth noting' comment from #15. I was about to say that you never restricted access to the individual fields using Field Permissions. Without doing this, you're not actually using the Field Permission module at all. You could disable the module (or spin up a clean Drupal 7 install) and you would encounter the same behaviour with the in-built image styles/the original image.

The private filesystem in Drupal isn't quite what you think - it doesn't automatically deny anonymous users access to files. For a given file, it checks which entities the file is attached to, then checks whether the user is allowed to view the file field it is attached to on that entity. If so, it allows them to access the actual file through the private file path; if not, it denies access.

As an example, if you unpublished your Article, the private file url wouldn't work anymore for anonymous users because they don't have the permission to view unpublished content. Yet administrators could still use the url to see the file, as they have adequate permissions.

In your test, anonymous users are allowed to view site content. An anonymous user can therefore view the entire Article, including its Image field. If the private file system blocked access to the image by default (as you expected it to), the user wouldn't be able to see the image on their screen when viewing the Article. This would contradict the permissions that had been set up, which allowed them to view it. When a user is allowed to view a file field, they need to have access to the private file path in order for the file to be properly served to them. This is reason why anonymous users can access the private file path in your test.

To restrict users from accessing a private file, all we need to do is change the site permissions so that they can't see that particular file field on the desired entity. This could be done in a number of ways: limiting view access to that specific entity (e.g. by unpublishing it); limiting view access to the entire entity type (e.g. restricting view access for a content type using the Content Access module); restricting individual field permissions (using the Field Permissions module); etc. We can use Drupal's powerful and granular permissions to manage access to the file field within an entity, and it already deals with access to any private file paths for us.

The original issue and #5 describe that the permissions to allow/deny viewing of a field (as set in Field Permissions) weren't being respected. This was fixed since the Drupal core fix mentioned in #12, so I'm closing the issue.

Just to confirm to anyone else: if you are using a private file system and use Field Permissions to restrict access to a File field, access to the file download itself is also restricted.

Great, thanks for clarifying that LGLC.