By anner on

I am trying to set up my drupal instance to handle 2 types of information, sensitive and public. I have found there is great power in the taxonomy access controls (thank you for that module), but have run into an issue when it comes to images. If I upload the image using the image content type, I can access it directly with the url (insecure). If I create an image field on my (thanks for flexinode too) own content type, it appears to be loaded only directly into the DB (secure), but they are not available by someone with the correct permissions to be accessed from another page. It would have to be uploaded again. The problem is, I want the images available in a gallery or repository of some kind, but I want that protected. Is there a way to add the taxonomy term selector into the image type? Can someone think of another way to do this? I'm completely open to suggestions. Thanks in advance,
Anne

⋅ Categories: Drupal 4.6.x

Comments

Brian@brianpuccio.net’s picture

Brian@brianpuccio.net commented

Change your settings to use the privaet download method and than any images you create will not be publically available through their URI.

anner’s picture

anner commented

If I do that then I get access denied if I try and access it via it's node (ex. http://mysite.com/node/46) but if I try and access it via it's actual URI (http://mysite.com/files/images/thisimage.jpeg) I can still access it.

pz’s picture

pz commented

I believe you have to change the rights for the directory where the private files are stored for that to work.

anner’s picture

anner commented

No, either the web server can access them or it can't. If I set it so the web server can't access it (600 on /files), then it doesn't come up even if a person is logged in (of course), but if I set it so the web serber can access it (700 on /files) then it is accessible by it's direct url, which looks like http://www.myserver.net/system/files?file=picturename.gif ...this is a big potential security risk for attachments and images to be available to anyone. Is there any way to load attachments and images in a secure way?

OK, I've found that the attachment module apparently has a patch for this (the upload module can't do it I guess), but have run into the identical issue...the private directory need to be:

This directory has to exist and be writable by Drupal. This directory should not be accessible over the web.

How can it possibly be writable/readable by drupal but not by the web server? I guess I must be missing something important here.

Anne

halftone’s picture

halftone commented

I wonder if .htaccess is the answer, in your files dir. Perhaps

ORDER DENY,ALLOW
DENY FROM ALL
ALLOW FROM 127.0.0.1

Should prohibit access from external addresses but allow access by Drupal itself running on localhost.

See http://httpd.apache.org/docs/1.3/howto/auth.html

Regards
Tony Sleep

anner’s picture

anner commented

I see your point and thought it would work, but when I tried it, I could still access the files when logged out of drupal. Other ideas on how to make something accessible to drupal and not to the web in general? If these instructions come with this module, someone must know. Please help. thanks.

halftone’s picture

halftone commented

What I suggested can't work for URL's like

http://mysite.com/system/files?file=images/mysecret.jpg

because Drupal is doing the serving anyway :(

http://drupal.org/node/26601 deals with the same issue, and has a few suggestions.

You could, I'm pretty sure, devise an .htaccess that would rewrite URL's of that form and point them at a dummy.jpg, for external referrers only (so Drupal itself can still fetch .jpg's for module use). But I'm not competent enough with Apache mod_rewrite & regexp's to attempt it right now - too many other things I need to sort more urgently.

http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html if you're desperate enough to attempt it. You'll find clues if you search for 'mod_rewrite stop leeching hotlinking' on Google - not the same scenario, I know, but adaptable. The trouble is that referrer is fakeable, so this method is only ever going to stop casual direct access.

Regards
Tony Sleep