in reply to Displaying Image located outside web server dir

Here's the basic logic. You'll want to insert whatever extra logic -- but this won't stop anyone from downloading it, as once it's in their browser, they can do anything they want with it. (it can be used to check to see if someone's directly linking to an image, if the browser sends HTTP_REFERER)

#!/usr/bin/perl -- open (IMAGE, '<', '/path/to/image') or print "500 Server Error\n\n" and exit; print "Content-type: image/gif\n\n", <IMAGE>; close (IMAGE);

In reality, you want to send the correct MIME type for whatever image you're sending, and send additional headers (cache-control, size of the file, etc.)

The times that I've done image rotating scripts, I've saved a copy of the image, with full HTTP headers, so I could just dump out the file contents without needing to do any extra parsing to generate headers each time around.

Replies are listed 'Best First'.
Re: Displaying Image located outside web server dir
by perleager (Pilgrim) on May 07, 2005 at 17:37 UTC
    Hey

    I was just thinking about this topic because I will probably be doing something similar.

    What if you used perl to copy the image to a directory inside your web server directory, then have it displayed through html like normal, then after thats done, have perl delete the image you copied? (sort of like a temp file)

    That way the image can be displayed, but when someone tries to save, it will not find the image since its deleted?

    I'm not sure if this method will work. Anyone have any comments on the flaws with this method?

    perleager

      Once the browser has it, they have it in their cache, and can regenerate it from the cache. It doesn't matter if it's still on the webserver or not.

      As eibwen mentioned -- the file has to be available to the browser for it to be displayed. You have absolutely no control over what the browser can do with an image once they have it. (I've seen sites that use javascript so they can try to keep you from right clicking on an image, but that doesn't help someone linking directly to the image (not through the page you intended), or just turning off javascript.).

        Ahh didn't think about that. I knew that there had to be some way to work around that method, just couldn't think of it.

        :)
      This could turn ugly very quick, with all kinds of race conditions rearing their heads. How do you know when to delete the file? What do you do if the connection gets broken before the whole file is transmitted? You could end up with lots of "old" files sitting around which will need to be reaped after some time. What if several requests come in almost simultaneously? You can't have different files, so all requests will have to "share" the same file and you will need to implement some locking system.

      I don't think it is worth the trouble as anyhow once the file is transmitted to the browser, there is no way you can stop him from saving the file.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law