I’m constructing a website where users can upload their images and share it with family and friends. Where is the best place to store these images? Outside the public_html directory and use file_get_contents() to display them? Or just put them somewhere in the public_html directory and use the <img> tag to display them? Can someone please tell me what the advantages and disadvantages are for both options?
If you decide to store all your images in public directly and link to them directly through <a> tag in a HTML page, you wouldn’t be able to authorize the users who are requesting access to a particular image. For example, John could see the images of Jenny if he knows the URL. On the other hand, If you store your images in a secured location and display them off a php script ( as in image.php?pid=12313), you can enforce all sort of permission and restriction rules.
But won’t John still be able to see the image of Jenny if he knows the URL “image.php?pid=12313” ?
Not if you place a permission checking layer behind the image request.
Can you elaborate on this?
Because I believe that if you display an image with <img src=“image.php?pid=12313”>, then you can always display the image by typing (http://…/)image.php?pid=12313 as URL in your browser and even hotlink to the image with this URL.
You can type/hotlink it, yes.
But if image.php contains the lines:
if(!isset($_SESSION['username']) || $_SESSION['username'] != SomeTestToCheckPermission) { die(); }
being able to hotlink it wont matter much.
As Odds pointed out, you would have to bolt on a permission checking layer in the script that displays the image. Here is how this page (index.php) would work?
- Get image id ( $_GET[‘id’].
- Run a query against database to see if the image being requested belongs to the currently logged in user (or if the current user is authorized to access the image.
- If authorization succeeds, retrieve the filename of the image with that particular id off the database, read the image file and finally serve it.
- If authorization fails, send out 404 HTTP status code.
hope you get the idea.
As Odds pointed out, you would have to bolt on a permission checking layer in the script that displays the image. Here is how this page (index.php) would work?
- Get image id ( $_GET[‘id’].
- Run a query against database to see if the image being requested belongs to the currently logged in user (or if the current user is authorized to access the image.
- If authorization succeeds, retrieve the filename of the image with that particular id off the database, read the image file and finally serve it.
- If authorization fails, send out 404 HTTP status code.
hope you get the idea.
For my framework what I have done for a image request is set-up my application as normally but the master template is blank, the header changes and images binary data is dumped. This makes it possible for me to do everything I could with a normal request with a image request. So even though I don’t currently have permission, logging, tracking layers they could be easily added. I’m also able to apply transformations to a image such as; resize, crop, grayscale, etc. This is a HUGE benefit of using a script to serve up images.
My image request looks like this:
/img.php/portfolio/pk_9/img_4.jpg/w/153
How this works is that img.php looks inside a root image directly. I than explode everything following the img.php to build the relative path to the image. Where the extension is found is the end of the path and start of any transformation options.
So in this case the image is located in:
[ROOT_IMAGE_PATH]/portfolio/pk_9/img_4.pjg
That image is than going to be resized to a width of 153px.
Transformations in themselves are an unparalleled benefit of serving up images with scripts. Not to mention the ability to regulate requests.
For my framework what I have done for a image request is set-up my application as normally but the master template is blank, the header changes and images binary data is dumped. This makes it possible for me to do everything I could with a normal request with a image request. So even though I don’t currently have permission, logging, tracking layers they could be easily added. I’m also able to apply transformations to a image such as; resize, crop, grayscale, etc. This is a HUGE benefit of using a script to serve up images.
My image request looks like this:
/img.php/portfolio/pk_9/img_4.jpg/w/153
How this works is that img.php looks inside a root image directly. I than explode everything following the img.php to build the relative path to the image. Where the extension is found is the end of the path and start of any transformation options.
So in this case the image is located in:
[ROOT_IMAGE_PATH]/portfolio/pk_9/img_4.pjg
That image is than going to be resized to a width of 153px.
Transformations in themselves are an unparalleled benefit of serving up images with scripts. Not to mention the ability to regulate requests.
Yes, transformation is yet another benefit you gain when you serve an image off a PHP script.
As an aside, one thing you should be aware of is that image transformation is an expensive operation in terms of both processing cycles and memory. So if you find that you are repeating certain transformation over an over again (like creating thumbnails in the fly), it’s more efficient to save a copy of the resized image itself and then serve it from there instead of resizing it every time the thumbnail is accessed.
Yeah, as Kailash Badu pointed out you’ll need some type of caching mechanism anytime your transforming an image on the fly. That is something I also have within my framework. However, its bit of topic. None the less, transforming requires some type of caching layer to be practical.