I want to set permissions for uploaded files in a way that only authenticated users (or users with any particular role) can access/download. I don't want to just hide the files but want to deny access completely. So if someone has the direct file URL, he should be logged in to access it.
Private files folder: I managed to set it up so that only admin user can access the files, but for authenticated users if access denied.

Comments

bhanojee created an issue. See original summary.

catch’s picture

Priority: Critical » Normal

This is a support request I think, but leaving as a bug report for now.

If files are referenced by an entity that an authenticated user has access to, then they'll be accessible to authenticated users. Can you confirm whether you're uploading the files via core's file field or via some other method?

bhanojeerao’s picture

Thanks for the reply catch.
I am using core's file field for uploading the files.
I have a custom content type, i created a file field for this content type in manage fields section.
I added content under this content type, each content having its uploaded file (text, document, PPT etc). When i view this content in the front end then i can see uploaded file.
So anonymous user should not have access to this file. I want the same logic for entire website where i have file concept.

Opinder Thakur’s picture

Using Module Field Permissions, Site administrators able to set field-level permissions to edit, view and create fields on any entity according to the specific roles.

Using this module we can set the permission of download file for authenticated or anonymous users.

bhanojeerao’s picture

I already checked this module Field Permissions (https://www.drupal.org/project/field_permissions).
This is hiding the fields from users when i set permission. As i mentioned in question, I don't want to just hide file/field but want to denied access completely when user clicks on the link.If we hide fields then user can not come to know that there are some fields for authenticated users.
Please help me on this.

bhanojeerao’s picture

Any help on this ?

chiranjeeb2410’s picture

Issue summary: View changes

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

zanvidmar’s picture

I have similar problem and I solve it like this:

I created custom module which ads cookie (user_cookie_save()) based on user role on log in (hook_user_login()) and delete it on log out (hook_user_logout()). I created "private" folder with .htaccess that allow access based on this cookie value.
This means that private files must be in this folder - separated form other files.

In my case I have only 2 options for users (can see, can not see file) but if you have multilevel permissions this solution probably won't work.
I know that this is not super secure technique, but in my case it is enough to stop bots and regular user to access this files.

If you are interested, I can share my code.

cilefen’s picture

Category: Bug report » Support request
Status: Active » Postponed (maintainer needs more info)

Does hook_file_download not work for the use case in the original post?

zanvidmar’s picture

I did not successfully find a solution to use hook_file_download if someone has the direct file URL - it seems that Drupal is not included in file rendering process at all.

From Drupal Docs (hook_file_download)
"This hook allows modules to enforce permissions on file downloads whenever Drupal is handling file download, as opposed to the web server bypassing Drupal and returning the file from a public directory."

So how can we force Drupal to handle file display/download if user has direct URL?

cilefen’s picture

Do you mean URLs to the public file system?

zanvidmar’s picture

cilefen’s picture

@zanvidmar I see. The subject of this issue is the private file system. The public system is, well... public. I suggest opening a forums thread to discuss.

seirerman’s picture

Did you check out the content access module (https://www.drupal.org/project/content_access)?

I use it for content types with private file fields, an depending on the permission I set for the content type (or even a specific node) anonymous users can either see the node (and the attached file!) or not.

If not, they get an "access denied" error for both the node and the file by drupal.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

alx_benjamin’s picture

Try this:

use Drupal\Core\Access\AccessResult;

function hook_entity_access(\Drupal\Core\Entity\EntityInterface $entity, $operation, \Drupal\Core\Session\AccountInterface $account) {
  return AccessResult::allowed();
}
kumkum29’s picture

@alx_benjamin

I search to create a custom access to the files of the site (depending by roles). Your code is an interesting base code for entity access.
In your opinion can I use this code for the files?

Thanks for your help.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

josedsilva’s picture

Thanks @alx_benjamin #17 worked.
#18 @kumkum29, yes you can use it with files. $entity->bundle() == 'file'

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

cilefen’s picture

Status: Postponed (maintainer needs more info) » Fixed

It looks like there is an answer.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.