what would be the best way to store images for a dynamic slideshow.

[alexandre]

i have this shopping cart feature that i integrated to my website and i noticed that the developer was storing the images in a imgs directory in the shopping cart directory and simply adding the name of the image file to the database, but i also saw that you can store images directly in database. what i want to do is a page to display the foundations's front presentations as a tiktok style vertical slideshow. it doesnt seem to be complicated to achieve if i dont want to make that swiping effect and just use the scrolling effect of a webpage,  if i store the images in the database. a simple loop through all the images would display them all fine(if it is possible to do so). i could also make them clickable easily to lead to the selected foundation "profile page". i am just wondering if i should use one method or the other. maybe for storage capacity reasons or any other issues related with storing images in database.

[Barand]

Store them presized to the size you want to display. Don't download images whose sizes are 4800x3600 only to display them as, say, 960x720 - it's going to be unnecessarily slower to download them.

[alexandre]

i am building an admin dashboard page and this will be from where i will upload the images needed. i disapoint myself a bit , i wanted to allow users to register their legit and confirmed foundations so they can create their own "foundations profile page"  and upload their own image for the front display. if i find the way to verify the foundations  is it still the best way to store the images? i mean , if the file will be coming from the users , i dont know if it makes a difference.

[ginerjm]

Legit? foundations? front display?   Terms I am not familiar with.

[alexandre]

i hope so i am using my own words to describe what i am trying to explain 

[alexandre]

if you prefer foundations registered with the governmental approval or something like that😅

Edited December 9, 2022 by alexandre

[gizmola]

In general, images are best stored either on a filesystem or in a CDN like cloudfront or akamai.  It's enticing to store them in a database that you are already using, but it's highly inefficient.  Blob storage in databases is expensive considering that you must query the result from the database in order to then return it to the client.  What most people do instead is have a table that stores a path to the image, so that you can have the best of both worlds.  

[alexandre]

On 12/12/2022 at 2:47 AM, gizmola said:

In general, images are best stored either on a filesystem or in a CDN like cloudfront or akamai.  It's enticing to store them in a database that you are already using, but it's highly inefficient.  Blob storage in databases is expensive considering that you must query the result from the database in order to then return it to the client.  What most people do instead is have a table that stores a path to the image, so that you can have the best of both worlds.  

sorry i didnt get the notification of your answer.

this brings me another question , if i let users upload images, to then store them in a folder with a path stored in a table in database, do the storage is handled by the hosting provider or do this still rely on my laptop storage? i never hosted a website that i programmed myself before so i am clueless about how this work.

[ginerjm]

If your users are doing uploads (that you have to setup btw) then those files will be on the server not on your device.  What you have to do is decide on where you will store them and how you will point to them for your app.

[alexandre]

i understand , thank you . and yes i know that i have to setup the uploads.

[gizmola]

1 hour ago, alexandre said:

i understand , thank you . and yes i know that i have to setup the uploads.

 

The basics of how PHP handles files is that you set in your php.ini a temp directory.  Uploaded files go into this temp directory.  You then use the function move_uploaded_file to move it to a destination. 

What you want to do is use some sort of hashing technique to come up with a name for your file.  Typically people also do hygiene on the files, checking things like the extension, mime type, and since these are images, there are routines in the libraries you can use to try and read the meta information from the file and determine that it is what it says it is.  You don't want people uploading malicious files that look like images, but are actually root kits or something bad.

At the point you are confident that it's a valid image file you want to keep, have your routine create a new name for the file.  Do not use or trust the name provided by the uploading user.  You can save this name in your database table as "original_name" or something similar if you want.  Just keep in mind that people can upload files with all sorts of wonky names containing file path characters and spaces, and you don't want to use those for anything.

What most people do is concatenate some things together and pass that to a one-way hash routine like md5 or sha1.  Your table should also have the mimetype of the file.  Then store the file where you actually want it to be.  Whether you want something sophisticated or not depends on you.  For example, for organizational purposes, you might want to make subdirectories (your code would need to do this of course) for each authenticated user.  This is all up to you.  Many people choose to keep the files outside the webroot so that people can't navigate to them directly, but again that is up to you as to whether you want to secure the files in some way or not.  

So to summarize:

• You need an asset/media/image whatever table
  • You'll want these columns to store
    • mime_type
    • file_path
      • This is the directory path where you will store the file
    • file_name
      • This is the hashed name you will use with move_uploaded_file to store the uploaded file once you are happy that it is legitimate and you want to keep it
    • original_name
      • Up to you if you want to keep this or not
    • description
      • this is common, if the user is prompted for it.
    • user_id
      • If you track the user that uploads it.  You can also maintain this via a many-to-many table
    • created_on
      • Timestamp of the upload
• Don't accept/move files until you have tested that they are legitimate, based on what you want to allow
  • I believe at this point in time the mime_content_type function is a good way to do this for images.  Decide in advance what image types you will accept and limit those in the upload form and check in your php script.  You can never trust that someone malicious isn't using a tool to bypass the html/javascript checking you might have implemented in the user UI
  • Once you are happy that the file is ok, compute the name you will store, and make any decisions on the path.  Use these to do what you want with the file.  Some people will store the filename with the validated mimetype, but that is up to you as to how you want to handle it.  It does make it somewhat easier for you as sysadmin of your server to look at files in the directories where you are storing them and find a particular file for the purposes of examining it.  You probably want to do that if you do decide to store files below the webroot and allow navigation to them directly to be served by the server from a simple img tag.

[gizmola]

One thing I forgot to add, is that you need to insure that the input to the hash routine has enough things in it to have a high degree of confidence that the computed file name is unique.  So an example might be:

 

$fileName = sha1($user_id . $originalFileName . uniqid($mimeType, true));

 

Another interesting application of sha1, that you might find useful is the sha1_file function.  Optionally you could have a column in your asset table that contains this value, indexed.  Prior to storing the uploaded file, you can run sha1_file on it, and use this value to check if any other assets have been uploaded with the same hash.  This is a great way to prevent people from uploading the same file repeatedly, if that is something you want to prevent.

[alexandre]

it all make sense , and i think that i didnt really set up things completely like that, however i decided to not let users upload images since it was just one more thing to help me identify the charities, it wasnt a necessity , i instead just ask for the country where the charity is registered and the exact name. for this purpose the images wasnt really necessary but i might let the users choose for a profile picture so this might come in handy at some point. but like you was saying about malicious attempts to break my code , i have a hard time with everything that can create even the smallest security hole. i really dont mind creating a almost static website if thats what it takes to avoid security issues. i already use the minimum of javascript lets say a sidebar uses javascript,  and my global chat  is working without being in connection with any database but uses javascript.

this is my upload file that i was using to upload the images from users:

<?php
$target_dir = "uploads/";
$target_file = $target_dir . basename($_FILES["fileToUpload"]["name"]);
$uploadOk = 1;
$imageFileType = strtolower(pathinfo($target_file,PATHINFO_EXTENSION));

if(isset($_POST["submit"])) {
  $check = getimagesize($_FILES["fileToUpload"]["tmp_name"]);
  if($check !== false) {
    echo "File is an image - " . $check["mime"] . ".";
    $uploadOk = 1;
  } else {
    echo "File is not an image.";
    $uploadOk = 0;
  }
}
if (file_exists($target_file)) {
  echo "Sorry, file already exists.";
  $uploadOk = 0;
}
if ($_FILES["fileToUpload"]["size"] > 500000) {
  echo "Sorry, your file is too large.";
  $uploadOk = 0;
}
if($imageFileType != "jpg" && $imageFileType != "png" && $imageFileType != "jpeg"
&& $imageFileType != "gif" ) {
  echo "Sorry, only JPG, JPEG, PNG & GIF files are allowed.";
  $uploadOk = 0;
}
if ($uploadOk == 0) {
  echo "Sorry, your file was not uploaded.";
} else {
  if (move_uploaded_file($_FILES["fileToUpload"]["tmp_name"], $target_file)) {
    header('location: ../admin_panel/admin-home.php');
    exit;
  } else {
    echo "Sorry, there was an error uploading your file.";
  }
}

i am not sure that everything you said above is done there but i thought it was filtering it a bit.