Closed (works as designed)
Project:
Printer, email and PDF versions
Version:
6.x-1.12
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
25 Aug 2010 at 11:02 UTC
Updated:
4 Mar 2011 at 15:39 UTC
There was a change committed (1.3.2.74) which moved the code to rewrite URLs as file:// URLs from the main print_pdf_controller function into its own procedure (_print_pdf_file_access_images).
There were lines added in to the _print_pdf_tcpdf and _print_pdf_dompdf functions to call this procedure, but there was nothing added into _print_pdf_wkhtmltopdf. This means that wkhtmltopdf doesn't get URLs rewritten for private file systems and images in nodes don't therefore display in PDF documents if you're using wkhtmltopdf on a private file system.
I'm sure there was a reason for doing this, but in the meantime, I've added a line into _print_pdf_wkhtmltopdf which calls the function and it appears to work on my system.
If there's no reason to omit this, it's probably better to add the function call back into print_pdf_controller and remove it from the functions for each PDF tool, but in the meantime here's a patch for print_pdf.pages.inc which adds the line.
| Comment | File | Size | Author |
|---|---|---|---|
| wkhtmltopdf_local_files.patch | 117 bytes | davidredshaw |
Comments
Comment #1
jcnventuraIt was fully done on purpose. One of the things you have to do is to take out the '--disable-local-file-access', or else the file rewrite will not work anymore.
Basically, wkhtmltopdf can't be trusted to access local files. The reason is that it's too good, and you can write Javascript that could eventually compromise your site. So rewriting it back to a 'file://' is not possible. That's why there was a security tag on 6.x-1.11.
I'll have to trick Drupal into letting wkhtmltopdf access the files...
João
Comment #2
davidredshaw commentedI see. I did also add an --allow switch onto the wkhtmltopdf options line to allow access to the right directory. Have had a look at the security advisory (http://drupal.org/node/880392 in case anyone needs to look at it).
Would it work to add a configuration parameter for wkhtmltopdf which allows the admin to specify a file directory that is OK for the tools to access? If so the module could generate the required --allow parameter and also conditionally rewrite the URLs as file:// locations? This requires the admin to determine which files to trust.
Another option would be to do the same thing but to allow access based on the URL being an imagecache private files callback path (system/files/imagecache). This option would be simpler to configure (requires no user config) and perhaps more secure if you trust the imagecache directory but obviously less flexible.
We could also check that the file is an image but that would require more overhead which may not be acceptable.
What do you think?
Comment #3
jcnventuraI have just tested this, and there's nothing that needs to be done except to enable 'view uploaded files' to anonymous users.
Unless your server is not allowed to access itself, but I will assume that anyone that can run wkhtmltopdf can also modify their server's configuration to enable that access.
João
Comment #4
jcnventuraNo further info in more than two weeks. Closing the issue.
Comment #5
davidredshaw commentedDoesn't "enable 'view uploaded files' to anonymous users" defeat the purpose of using private files? If so I think this would still make sense to change.
Comment #6
jcnventuraNot really, you use private files to make sure that only visitors to your website can access your files (as opposed to hotlinking an image from your site from another site).
If you only allow your logged-in users to view your files, then casual visitors to your site won't be be able to access those images. And since wkthmltopdf is one of those casual visitors, it will never be able to access those images. Drupal will enforce the access restrictions just like you requested.
The only workaround would be to make wkthmltopdf login to the site with the same credentials as the current user. That would introduce so many complicatons that I don't even want to think about it.
João
Comment #7
davidredshaw commentedI think there are other reasons to use private files. In my case anonymous users don't have access to view files, but in others, a user could implement a node access module that used hook_file_download to restrict access to private files (for example based on node access permissions).
But I can understand not wanting to try to authenticate wkhtmltopdf.
I do think there are two ways around this
- as outlined above add a configuration parameter to print module allowing wkhtmltopdf access to specific directories. Would this be classed as a security issue?
- implement private files but keep the files directory within the docroot and protect it in the apache config. This would mean that regular file access would use private files and you could allow access using what would be the public URL to 'localhost' in the apache config - that way wkhtmltopdf can use the public url (would need to change the theme template to do this.
Comment #8
jcnventura@dreadshaw, about your questions:
1. yes it would be classed as a security issue
2. that's so complicated to setup that I really don't want to be providing that kind of instructions to users. If you want dompdf to access your files, you have to give him permissions for that (so enable 'view uploaded files' to anonymous users.).