Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
The direct path to an uploaded files does not permit download:
http://subdomain.example.com/sites/subdomain.example.com/files/private/file.pdf
The following link (subject to user having node access) permits download:
http://subdomain.example.com/system/files/private/file.pdf
However in Views under Upload: Attached files when 'Link this field to download the file' is selected, it is linked to the former, which fails.
Glad for advice on how to override this so that a private file can be downloaded from view results.
Webel
Comment | File | Size | Author |
---|---|---|---|
#14 | viewbefore.txt | 4.25 KB | YesCT |
#14 | viewafter.txt | 4.29 KB | YesCT |
Comments
Comment #1
Jody LynnSounds like a views bug to me.
Comment #2
dawehnerSry, here it works fine. Could you please try to export the view, perhaps there is something other.
Comment #3
webel CreditAttribution: webel commentedNow also with 6.x-2.x-dev.
This represents a confirmed security issue (not regarding core drupal security, just file and media access), so please inspect (with my sincere gratitude and encouragement in advance) a.s.a.p., and I will also respond promptly, and am actively tracking this again, thanks Webel.
An export of a very simple view of a linked node title (for a custom type Document) and Attached files as link
Comment #4
merlinofchaos CreditAttribution: merlinofchaos commentedI don't see how this could possibly be a bug in Views. Views uses the core API for creating the URL:
$file['filepath'] = file_create_url($file['filepath']);
If files are set to public it uses the direct path. If files are set to private it uses the system/files path. See http://api.drupal.org/api/function/file_create_url/6
If the private files module is not telling Drupal core that the files are private, I don't think Views can do much about it.
Comment #5
webel CreditAttribution: webel commentedRenamed from: Upload: Attached files: 'Link this field to download the file': does not work with private files
Comment #6
webel CreditAttribution: webel commentedHi merlinofchaos,
Wow, that was quick, thanks for reply.
Before I assign this back to Private Upload issues queue (i.e., excluding Views as a cause), I would like to confirm something.
You wrote:
I am not 100% sure what you mean here by 'set to public'. Do you mean:
1. It is set to public download method (not a part of Private Upload module)
2. On the file attachments upload dialog in the edit form the Private Upload module's 'Private' checkbox is ticked.
As far as I understand it, Private Upload handles files under the public download method, and instead relies on .htaccess in a special folder private
../sites/www.mysite.com/files/private/
.You wrote:
Again, do you mean w.r.t. the Private Upload checkbox, or the private download method ?
You wrote:
You may with this have identified this correctly as a Private Upload module problem
However could you please review the terminology and questions above, then by all means assign back to Private Upload,
many thanks,
Webel
Comment #7
Jody LynnI'm thinking there may not be a bug at all, but maybe your site is just misconfigured. webel. The private upload module is totally separate from the 'private' file system setting. There shouldn't be any paths to system/files involved.
I'm moving this issue to not take up Merlin's valuable time. I'd like to see someone else confirm a problem before looking into it.
Comment #8
mukhsim CreditAttribution: mukhsim commentedThis is the issue I run into:
When displaying file attachments in a view, file urls are incorrectly generated, instead of "BASEURL/system/files/private/FILENAME" the view displays "BASEURL/private/FILENAME". The url is being generated with private_upload_views_handler_filepath() (line 820). It seems that _private_upload_is_file_private() does not properly determine whether file is private or not.
My files folder is outside of webroot (../files).
Mukhsim.
Comment #9
webel CreditAttribution: webel commented@Jody Lynn, thanks, am following with interest, Webel.
Comment #10
gabidrg CreditAttribution: gabidrg commentedSame issue here, following this thread.
Comment #11
rsbecker CreditAttribution: rsbecker commentedThis probably is not a bug and really it does not matter. The solution is very simple.
You have two choices when setting up the Upload: Attached Files field in the view: Output the this field as a link, and Link this field to download the file. You should choose the former and output the field as a link and also includ the Node:Title field. On the Upload: Attached Files field set the Link Path to system/files/[upload_fid-name]. That will output the Title as a link to the file, using the right path to it, avoiding the Access Forbidden error.
Comment #12
webel CreditAttribution: webel commented@rsbecker
I had indeed ''Link this field to download the file".
I changed it as recommended to "Output this field as a link".
I set the Link path: to
system/files/[upload_fid-name]
I did not understand "and also includ the Node:Title field" (I of course know that a Node:Title field is, I just don't know what you mean be including it here or how/where, or why when I want to generate a link to the attached file). This is probably irrelevant to my case.
It works !
I am most grateful to rsbecker (and to all who responded) for this help, which is crucial for delivery of my current site to my client. This has been a good example of the Drupal community process working well (and I hope my own detailed description of the problem has helped invite that help).
And I can also see many other useful ways to use the flexible "Output this field as a link" facility, so thanks for alerting me to that alternative.
@rsbecker Please close on reading.
thanks,
Webel
Comment #13
webel CreditAttribution: webel commentedComment #14
YesCT CreditAttribution: YesCT commentedI have the same trouble.
I just noticed, after having the view up for a while, that I have a view that lists the 2 most recent posts of certain criteria that have files attached, and it lists the files attached, but the link is wrong.
it lists them as files_gslc/private/SS_May_2010.pdf and it should be system/files_gslc/private/SS_May_2010.pdf
I'm using the default views field upload: attached files
Elsewhere on the site the non-private (public) ones get generated by views fine (see orange public block on left a bit down at http://goodshepherdlc.org/ )
Attached is my export before I tried the fix recommended above, and after picking to rewrite the link (and unchecking the box: link this field to download the file)
Here is a diff of the files:
Comment #15
rimu CreditAttribution: rimu commentedI got this to work eventually, but not in quite the same way.
I needed to add the Upload: Attached files field to my view (before the Upload: description field that we are primarily concerned with) to get the [upload_fid] token available. Then I could use the 'rewrite output for this field' checkbox on the Upload: description field and put in
<a href="/system/files/private/[upload_fid]">[description]</a>
Comment #16
NickWebman CreditAttribution: NickWebman commentedThanks for everyone's useful advice. For me, the problem was in /admin/settings/file-system
I had it set to public instead of private.
Public - files are available using HTTP directly.
Private - files are transferred by Drupal.
Comment #17
mayerwin CreditAttribution: mayerwin commentedThanks n1ckhead, I solved my issue using your solution!
Comment #18
mayerwin CreditAttribution: mayerwin commentedActually I just noticed when running Cron:
"Private Upload will not work with file upload method set to private. Please enable Public File Transfer."
So i'll have to rewrite the output manually to make sure I don't break anything...
Comment #19
WorldFallz CreditAttribution: WorldFallz commented@N1ckhead: not sure why you're using this module then. The entire purpose of this module is so you don't have to use the private download method system setting, lol.
In any case, I just committed a fix for this for my module (download_count) which supports the private_upload module. With a little effort, it should be able to be converted to a views handler for this module-- I just don't have the time to get it to it right now. The commit for the relevant code is http://drupal.org/cvs?commit=380168. It's pretty simple actually, but afaict, this module doesn't have any views 2 integration (I only saw a comment about views 1, which was never upgraded to d6, in the code).
Comment #20
kraguel CreditAttribution: kraguel commentedSame problem here using Drupal 6.16 and not using modules known to have problems with Private upload (i.e. Upload Path nor Upload Image).
I have created a content type (Download item) to publish all downloads and a simple view to list these downloadable items.
Attachment links through the view are wrong (i.e. without ".../system/...") and I still have the same problem when retrieving the content of the node directly. Enabling private downloads for the whole site (as suggested by @N1ckhead) let private downloads start working properly but "Private upload" module starts complaining as noted by @mayerwin and no way to publish public downloads. That is, the "Private upload" turns out to be useless. And further ideas?
Comment #21
WorldFallz CreditAttribution: WorldFallz commented@kraguel -- read the entire thread. First, there's absolutely no reason to use private_upload with the private file system setting. Second, there's a solution above using the 'rewrite the output of this field' option in views.
Comment #22
rimu CreditAttribution: rimu commentedViews needs to use _private_upload_create_url instead of file_create_url, if _private_upload_create_url is available.
In views/modules/upload/views_handler_field_upload_description.inc (views 6.x-2.11) I now have
Comment #23
rimu CreditAttribution: rimu commentedComment #24
merlinofchaos CreditAttribution: merlinofchaos commentedAhh, no. It is the policy of Views' module to not add hacks specific to modules unless those modules are amongst the top contrib modules that may as well be core, such as CCK and the like.
Instead, private upload can attempt to swap out Views' handlers for its own versions that support it.
Comment #25
rimu CreditAttribution: rimu commentedAgreed. I've been reading lots of Views documentation since my last post in this thread...
Comment #26
diaxpro CreditAttribution: diaxpro commentedI read all and the solution of rewrite the link output in view not found if file is private...
File private:
system/file/private/[upload_fid-name]
File public:
system/file/[upload_fid-name]
Other solution?
Comment #27
rjacobs CreditAttribution: rjacobs commentedI'd like to track this.
Please note that it appears that the workaround highlighted several times above (manually rewrite the field output in the view) seems to have some shortcomings. Namely if you upload a private file that has the same name as a public file, the system will append a number to this 2nd file (renaming it), but there is no rewrite token that correctly captures this renaming. So if you already have a public file.jpg, the second upload of file.jpg may be saved as file_0.jpg, but the rewrite solution/method above will still list the filename in the view as file.jpg (instead of the correct file_0.jpg). This leads me to believe that there are other cases where the filename may be mis-represented (and therefore incorrectly captured in the view link)
Anyway, there seem to be some cases where this solution breaks down. Sean Porter outlined more details here: #706672: Private Upload renames duplicate files, but doesn't update File: File Name in views.
It was also noted that this problem is not a bug. I suppose that is indeed true if views support is not a key expectation of private upload. I guess I don't understand enough tech specific as to how these two modules play together... but it does seem buggy IMHO.
Comment #28
rjacobs CreditAttribution: rjacobs commentedThe issue here: #306933: Accessing file from views implies that this problem is due to the fact that private upload only has views 1 compatibility. Furthermore, #306993 seemed to start some momentum to add views 2 support.
As stated in comment #4, the problem seems to be that while views supports the core Drupal "private files" setting, private upload requires that "public files" be set.. even though it leverages the private files concept internally.
Does that mean that this issue is a duplicate of #306993?
Cheers,
Ryan
Comment #29
rjacobs CreditAttribution: rjacobs commentedOk, a patch is now available at #306933: Accessing file from views which I believe does what merlinofchaos suggested in #24 to address this problem. As a result, I'm marking this as a duplicate... please feel free to toggle the status back if I am missing some reason why this is actually a different issue.
Ryan
Comment #30
rjacobs CreditAttribution: rjacobs commentedPeople viewing this issue may also be interested in: #636516: Option to use "mod_rewrite" in .htaccess rather than "deny from all" (avoid "Access Denied" errors from incorrect file paths)