Private Files not being retrieved

It seems to work for me. But it was a little trick. Supposing your files folder is at sites/default/files, and your private files folder is at sites/default/files/private, and you have a folder in there called images, and your default download method is set to "private" at "admin/config/media/file-system", you could make it work like this:

[filetree dir="images"]

All those files will be written with their private files URL.

With the same assumptions as above, except this time your default download method is set to "public", you'd have to use this value:

[filetree dir="private/images"]

However, it should be pointed out that in this second example, your files will be written with their public URL, which of course will return 403 Forbidden when clicking on them.

Hope this helps!

That's how it seems. There may be a way to determine whether or not a file should be displayed with a public or private URL... but I don't know how to do that. I welcome any patches.

Marking #1258436: [PATCH] Add private file downloader as duplicate, and opening this discussion back up, since it seems that we don't yet have a good solution for private files.

There are obviously security issues here. Please provide use cases (scenarios) so we can find a generic way to solve this that won't cause security problems.

Well, in terms of use cases there are (at least) two ways of looking at this problem:
1. The administrator publishes a file tree. Different files in that tree belong to different users. Therefore permissions should be arranged on file system level. Eg: keeping a list of Drupal roles for each folder.
2. The administrator publishes a file tree. All files inside that tree are "published", and therefore should be accessible by anyone with rights to see the node where the file tree is in.

Option one (folder level) is fairly easy to implement, and has many ways of doing so. In fact, this could be implemented into a separate "private file downloader" module, not really related to Filetree. The easiest way is to introduce a hidden file that defines the roles that have access to the files and folders inside. That way no traces (database mess) are left when you remove a folder. Downside is, as stated before, adding another layer of role management. Also, rendering the tree must adhere to these permissions as well to be practical.

Option two (filetree/node level) would therefore have my preference with the existence of nodeaccess modules, but does not appear to be so simple to implement. The clear advantage is that it comes closer to an "it just works" environment. The admin doesn't have to worry about a new security mechanism but instead controls the node rights. The downside is that it involves quite a lot of work
- Downloads should be linked to the node that serves the file tree
- Upon downloading, it should be checked that the user has access to the node
- Upon downloading, it should be checked that the node is actually presenting this file.
Especially point 3 is difficult, as we would have to check the text input types to see if filetree is enabled, check all fields for this node to be of one of these types, and then scan the availability of one or more file trees in this node that then also needs to contain the path required.
Perhaps it's like swearing in church right now, but it might be easier to have a (complex) field type "filetree". Not only would this help in this problem by greatly simplifying the work of finding "what folders is this node serving", but might also give new ways of dealing with the caching problem of #1139866: auto refresh filetree listing or make real-time?. However I can only assume that the choice for a filter rather than a field type has been researched when designing this module, rendering this option undesired.

The (ruled out) patch in #1258436: [PATCH] Add private file downloader adds a simple private file downloader which is pretty much a copy from the IMCE module. It has great security issues, but might be useful for some controlled environments. However, I agree that a definite option should be found to serve private files. I personally however do not feel the solution should be sought in creating database items for the files in the tree. One of the major advantages of this filetree module is that it can handle something as dynamic as a (network) file system folder. Having to maintain a database of files (in a probably hacked up way) will make a filetree system probably lose that advantage as it will not be triggered whenever a change in the folder occurs.

subscribe

double post.

Please find attached the patch from RSpliet from #1258436: [PATCH] Add private file downloader. Minor non-functional changes, and includes #1313532: Admin settings page.

This will introduce a very simple download "manager", basically copy-pasted from IMCE.
This download "manager" is indeed an equally sized security risk. It however needs to be manually enabled, allowing administrators to deliberately take the security risk for granted. In controlled environments this might not be a problem, hence this patch can be useful in some use cases.

Attached patch is a rework of the original patch posted in #1258436. Improvements include better coding style (by using hook_help, by adding the variables in the install routine) and a "force file download" option to make the browser download instead of open in the existing window.

This patch invalidates the patch posted earlier. Fixes a nasty warning in hook_help() and now applies cleanly to upstream git without whitespace errors.

is this patch already checked in.? i tested this patch against filetree-7.x-2.1. and it fails.

.