age-old debate: images in db or dir?

[pnoeric]

ok - I'm working on a creative solution for the old problem of storing images in a database or in a directory. I need to authorize folks before I can let them see images, but I want to avoid the super-ugly .htaccess authorization pop-up window (I already manage usernames/passwords elsewhere in my app)... but i appreciate the dramatic performance improvement in letting apache serve the images and and not getting php/mysql involved.

so is there a good way to do this?

one creative idea i had-- dynamic re-writing of the .htaccess file. that is, after a user is authorized to see images in a directory, the .htaccess file is dynamically changed to add an authorized user on the fly. but what can i authorize on? the idea I had was to add "allow from" and an IP address, but I realized that if someone's surfing through a proxy server, the IP address can change with each request. is there a way to limit that behavior? OR is there something else I could put into an htaccess that would limit access without popping up the authorization dialog? (there's no way I could have the .htaccess file allow based on the cookie is there?)

thanks for reading, would love to hear y'alls thoughts on this strategy--

best
Eric

[pnoeric]

hmm maybe setting an environment var based on the Referrer will work-- I'm thinking something like this:

SetEnvIf Referer www.mydomain.com/imageverify.php ok
<Directory /docroot>
Order Deny,Allow
Deny from all
Allow from env=ok
</Directory>

so the way I would authenticate is: if they are ok to see the images, i would pass them to a special php script which in turn put them into the image directory, per above.

would that work?

-Eric

p.s. yeah I know this is more apache than PHP but there may be a part of the solution that involves PHP - any this is a smart bunch o' people too. so I figured it was a good place to ask.

[bastien]

DBs...the best way to manage this...you can have the user register and based on the registration data limit access to certain photos based on some kind of discriptor in the photo dataset (ie take age from user and not allow him to look at adult photos)

Also use the DB to store the map to the photo
and just call the text to insert that into the HTML tags...very quick as you only write the text and allows for 1 or two pages to serve all the photos.

hth
Bastien

[Anon]

Yeah, like Bastien sez, use a db for user registration, and storing links to the images.

If the image files aren't stored in the site directory tree but somewhere "off-site", then they'll be unavailable to anyone just trying to get site directory listings but will still be visible to PHP.

So the question is how you serve them up. You can have the script do that, too. the <img> src= attribute would refer to a PHP script, and that script will (a) check appropriate registration, (b) get the filename from the database, (c) fetch the image file itself from wherever it's hiding on the server, (d) echo it out in response to the original request.

<?php
...steps a,b...
$file=fopen("/path/to/images/".$filename, "rb"); // 'b' unnecessary except on Windows
$image=fread($file,filesize($file));
fclose($file);
header('Content-type: image/jpeg'); //Or GIF, or PNG, or whatever - figure this out from the filename extension
echo $image;
?>

Because the images aren't stored in your site directory structure, the only way that they can be seen by someone unauthorised is if they break into your filesystem. Chances are that then looking at unauthorised pics is the least of your problems.

[pnoeric]

right - so this cuts the database (mostly) out of the equation, at least in terms of moving big loads of binary data around-- that's a plus-- but i'm still not getting the advantage of letting the server serve the graphics directly.

I am thinking this will help me with things like letting the server cache images for repeated requests, etc... though I guess the cacheing would still work, esp. if I customized the url for each image, maybe with something as simple as an image ID ala a 'GET' request (i.e. "display.php?img=12313") -- I ASSUME (another way of saying, I'm guessing <g>) that this will allow the server to be smart enough to cache as it sees fit?

the goal here is to get performance, i like this hybrid approach; it looks like a database serve but it's really mostly a direct serve with PHP facilitating.

what do you think of my idea outlined above, using the .htaccess to limit via referrer? it's not as flexible but it is kinda cool. i need to test it to see if it'll work but i'd love to have folks punch holes in it now.

thanks for the replies,
Eric

[Anon]

Eric Mueller wrote:

right - so this cuts the database (mostly) out of the equation, at least in terms of moving big loads of binary data around-- that's a plus-- but i'm still not getting the advantage of letting the server serve the graphics directly.

Well, you said it yourself - it cuts out moving all those blobs in and out of your database. That's a huge performance gain, because you're no longer trying to use your database as a filesystem - you're using the filesystem as a filesystem.

As for your .htaccess-fiddling idea; I've never really considered it myself, partly 'cos I was reluctant to do all the parsing that would be required to seek and destroy entries.

[pnoeric]

ah but the system I proposed above has no actual fiddling-- it turns out I can just set the .htaccess file once and let it go.

I'm thinking of just doing the other method, though, because it requires less server dependancies, a consideration for app portablity..

thanks,
Eric