Private files support
| Project: | Dynamic Rendering |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
I was testing 5.x-1.x-dev (2007-Mar-02) and noticed that the path to the dynamic generated sifr-screen.css didn't work. This is what is generated in the html head:
<style type="text/css" media="screen">@import "//local_file_path_to_drupal_files/sifr/sifr-screen.css";</style>
(Where "local_file_path_to_drupal_files_directory" is the local file path to drupal files directory, unsurprisingly.)
This is caused by:
drupal_add_css(file_directory_path() . '/sifr/sifr-screen.css', 'module', 'screen');
in sifr.module. As I understand it file_directory_path() prints the complete local file path and when you're using a absolute path to a directory outside web root (something like "/home/account/domains/example.com/drupal_files/") this approach doesn't seem to work. But I'm pretty new to Drupal, so it could be me misunderstanding the whole thing too.
I tried to change it to file_create_url(), but that creates a complete URL and drupal_add_css() expects a path relative to the base_path().
I need something that will create something like /system/files/sifr/sifr-screen.css (but I couldn't make that work either, but that's another issue, it should work the same for a css file as an image file, right?)
#1
Forgot to say: This happens if you use the private download method, because then you have to use the system/files/ path to retrieve anything from the files directory.
But according to this only images will be retrievable at all, if it's not in the files table. So I don't know if it's such a good idea to put the CSS in the files directory.
#2
Sorry for the delayed response. It seems that you're right and we need a implementation of hook_file_download() in sIFR to let anonymous users access and download sifr-screen.css and any uploaded sIFR fonts.
I don't need that right now, so who wants to code this?
Please bear in mind that you will also face other problems with the private download method. I've dealt with a similar scenario in the past and found out that using a public download method together with a .htaccess secured subfolder in
/filesis the best practise I can recommend.#3
My solution for the moment was to copy the CSS code from sifr-screen.css and put in my theme CSS file.
Interesting to read about your recommendation for download method, I'm still pretty new to Drupal and I haven't read about the private method causing trouble before (when reading about choosing method). I'll try that method on my next Drupal installation.
#4
#5
Maybe useful a check if the file storage is public or not. Then in case of private storage maybe useful setting 777 the sifr/sifr subdir and store the whole files there instead. Or to store them there by default with no care of file storage.
#6
Hi,
First of all: this sIFR module is huge!
Now, let me explain the way I handle Private Files issues: using Symbolic Links - so security should be OK... (tell me if I am wrong, please)
1) Modify render.module - assuming you still have your public files directory named "Files"
line 767 - render.module
// $dir = file_directory_path() .'/render/';$dir = 'files/render/';
2) Create symbolic link on your server (through SSH for example) - probably as root
cd your/publicFiles/directoryln -s /absolute/path/to/your/privateFilesDirectory/render ./render
3) DO NOT FORGET to change User and Group owner for the symbolic-link with -h option (no-follow)
chown -h userForDrupalDirectory renderchgrp -h groupForDrupalDirectory render
Nota: groupForDrupalDirectory is usually "users" on Linux
Adapt it.
Should be working fine. Give me feedback :-)
Naturally, this can be used with many other modules which do not consider properly PrivateFiles
e.g. Color on Garland, imageCache... See what I mean ;-)
Alexandre
#7
Subscribe
#8
I don't agree with this. If you use hook_file_download() in the Rendering module, then only logged in or users with download permission can see the rendered text. Is that what we want? Is not the looks of a site for all to see? Only files are to be protected, not the visual aspects of a site. I would suggest to place the rendering stuff in a separate file folder independent from the normal files folder (wherever that is located, secure or insecure), may be a folder of the module's folder?
#9
com2: You are suggesting something that Drupal core currently does not support. We have to hack around this limitation.