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?)

Comments

AdrianB’s picture

AdrianB commented

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.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

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 /files is the best practise I can recommend.

AdrianB’s picture

AdrianB commented

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.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: Is file_directory_path() really the right thing to use? » Private files support
Project: sIFR » Dynamic Rendering
Category: bug » feature
Status: Active » Postponed
tassoman’s picture

tassoman commented

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.

sashainparis’s picture

sashainparis
Primary language French
Location Provins
commented

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/directory
ln -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 render
chgrp -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

greenskin’s picture

greenskin commented

Subscribe

ñull’s picture

ñull commented

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?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

com2: You are suggesting something that Drupal core currently does not support. We have to hack around this limitation.

sashainparis’s picture

sashainparis
Primary language French
Location Provins
commented
Issue summary: View changes
Status: Postponed » Closed (outdated)