Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 2 of 2 FirstFirst 12
Results 16 to 17 of 17
  1. #16
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by tangoforce View Post
    True however an MD5 hash is only 32 characters. At some point some other content may generate the same hash. The hash doesn't increment like a database table can, it's a fixed length and at some point, something somewhere will generate that very same hash (though not necessarily on your site / server).
    Then why not use this...

    hash_hmac_file


    Quote Originally Posted by tangoforce View Post
    You promised to keep that quiet Now what are my two mates Fou-Lu and firepages going to think of me?
    A real man wears his Superman outfit and tights with confidence!

    Don't let them tear you down Tango. Stand your ground!!



    Quote Originally Posted by tangoforce View Post
    No not really. Like I said, replace the blob and you won't need to *delete* anything or let the user run a script that can *delete* somthing.
    You're losing me here...

    My business rules says, "Only one instance of a given image can exist on the website."

    The way I currently determine uniqueness is by using hash_file - regardless of where the image gets stored.

    You can swap out Images on the File System or in the Database, but there still needs to be a mechanism that says, "This Image File ever only occurs once."

    If I swapped out Images, then I'd also need to re-run hash_file and make sure the Image doesn't already exist.

    That is *independent* of whether this happens on the File System or in the Database.

    Follow me?


    Your idea has merits, but I am thinking that mlseim's suggestion may have less side-effects.

    What does everyone else think?


    Quote Originally Posted by tangoforce View Post
    Remember though, resizeing an image by just one pixel will generate a totally different md5 hash.
    Duly noted.


    Quote Originally Posted by tangoforce View Post
    I think there is a 'fear' or it myself amongst web developers but in many other languages it's common to store images in a database table. When it comes to websites though, people frown on the idea and think its a terrible idea.

    For a start the server isn't running a lot in the way of graphics meaning the processor doesn't spend half it's time refreshing the form on your desktop and instead can burn those cycles doing 'system' stuff instead. Then you have to remember that most servers have superior CPU power over a desktop PC and can pick out a record from a table in a split second.
    I don't have enough expertise to comment either way, other than people that I do trust in the database realm have almost always said that storing Files in a Database is not a good idea.


    Quote Originally Posted by tangoforce View Post
    Yeah but you just revealed to my two biggest fans that little secret we had

    Right.. with that said, I must fly...

    Nice touch!!!

    Sincerely,


    Debbie

  2. #17
    Regular Coder doubledee's Avatar
    Join Date
    Mar 2011
    Location
    Arizona
    Posts
    939
    Thanks
    21
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by mlseim View Post
    I'm not sure of the odds that two different graphic images would have the same exact filesize (in bytes).
    Extremely common!!

    That's almost like asking, "I wonder how many books in the library have the same number of pages?"



    Quote Originally Posted by mlseim View Post
    EDIT:
    And the CRON job to delete unused photos would still use UNLINK.

    The CRON is a scheduler that executes one of your PHP scripts at a given time.
    But if I stored the "delete-unused-photo-files.php" file OUTSIDE of the Web Root, and only my CRON job could run it, then it wouldn't be easily accessible to a hacker.

    Whereas if I place unlink() in my "upload.php" script which resides in the Web Root, then any hacker that accesses that file could conceivably get around my best coding attempts and go crazy deleting files, right??

    If I take that functionality and stick it somewhere that only allows "me" or a "CRON job" to run it, then I would think I have greatly reduced the risks...

    Sorta like, "Don't give greater access rights to any one user than are needed to do his/her job."


    Quote Originally Posted by mlseim View Post
    The idea of images in their own sub-directory is a good idea.
    Actually, is that a good or bad idea?

    I wouldn't want to give Jane User the ability to upload files *outside of the Web Root*, right?!

    The more I think about it, isn't it safer to "sandbox" uploaded images and keep them *inside* the Web Root?

    Gee, that is a whole new scary topic for which I don't know the answer...

    Sincerely,


    Debbie


 
Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •