Randomise upload filenames (or another solution to hide the original image URL from theft?)

Question

Our users upload high resolution artwork that we need to protect from theft. The images are resized and watermarked, but it's still trivial for somebody to guess the original URL and gain access to the full resolution image.

I'm trying to figure out a solution, the easiest (I think?) being to randomise the filenames. I can randomise filenames on upload using something like:

function randomize_uploaded_filename( $filename ) {
    // Do things...
    return $filename
}
add_filter( 'sanitize_file_name', 'randomize_uploaded_filename', 10 );

however this will change the filename before wordpress scales the images. No good.

I can also rename the scaled sizes as they are generated so that they each have a unique random filename (used in conjunction with the above this would mean that all image files can have unguessable filenames, right? almost....):

add_filter( 'image_make_intermediate_size', 'rename_intermediates' );
function rename_intermediates( $image ) {
    $info = pathinfo($image);
    $dir = $info['dirname'] . '/';
    $ext = '.' . $info['extension'];
    $name = wp_basename( $image, "$ext" );

    $randomString = '' // random stuff here

    // Build our new image name
    $new_name = $dir . $randomString . $ext;

    // Rename the intermediate size
    $did_it = rename( $image, $new_name );

    // Renaming successful, return new name
    if( $did_it )
        return $new_name;

    return $image;
}

But, if I do this, wordpress doesn't remember the new filenames. So if the original file is uploaded and saved as, say, painting.jpg , and the scaled versions have some randomised filenames like jkn4jk53u567u.jpg , wordpress will still think that the scaled version is called painting-scaled.jpg , etc. Resulting in broken images.

Where am I going wrong? I really appreciate the help :-)

Edit - Here's the second portion in full as per @SallyCJ 's request:

add_filter( 'image_make_intermediate_size', 'rename_intermediates' );
function rename_intermediates( $image ) {
    // Split the $image path into directory/extension/name
    $info = pathinfo($image);
    $dir = $info['dirname'] . '/';
    $ext = '.' . $info['extension'];
    $name = wp_basename( $image, "$ext" );

    // Generate a random alphanumeric string
    $randcharacters = '0123456789abcdefghijklmnopqrstuvwxyz';
    $randcharactersLength = strlen($randcharacters);
    $randomString = '';
    for ($i = 0; $i < 8; $i++) {
        $randomString .= $randcharacters[rand(0, $randcharactersLength - 1)];
    }
    
    // Build our new image name
    $new_name = $dir . $randomString . '-' . $name . $ext;

    // Rename the intermediate size
    $did_it = rename( $image, $new_name );

    // Renaming successful, return new name
    if( $did_it )
        return $new_name;

    return $image;
}

Edit 27th Feb 2021 in response to Sally CJ's answer:

I apologise for my slow reply, it has been a busy few days! Firstly, thank you for your incredibly educational and detailed response! :O

Your fix is fantastic but not quite working fully for me, I'll explain. When I upload picture.jpg it generates everything as you've said, and Wordpress can now correctly see the location of the original AND scaled image (e.g. 768O4Y7q-picture-scaled.jpg). Brilliant! It can't see all the smaller sizes, though. On the Media Library (upload.php) page it thinks the smaller size BFcUGvP8-picture-100x100.jpg image used as the thumbnail is called picture-100x100.jpg. However, in other areas it can see other various renamed smaller sizes sizes just fine...

I've also noticed that when regenerating smaller sizes it adds another 8 random characters to the start of the filename each time (based off the "new" original filename), and it doesn't delete the old smaller sizes during regeneration. It saves new ones alongside the old ones. Ouch! That's a big problem that'll cause exploding disk space use haha.

This is touched upon briefly on the wp_generate_attachment_metadata reference page:

"This function can be used to regenerate thumbnail and intermediate sizes of the image [...] but it does not check or delete intermediate sizes it previously created for the same image."

There are a few other big issues with the image regeneration, too.

At this point the issues that remain are:

1. The new smaller size locations aren't all being updated, leading to some broken smaller size images (could it be custom image sizes causing the issue? Is 100x100 a custom size?)

2. Image regeneration doesn't delete the old generated smaller sizes.

3. Image regeneration seems to re-check the "original" file's filename and draw from that, which reveals the random string at the start that "hides" it. Also, it prepends the original file with another set of random characters, e.g. JGcYJrP9-picture.jpg would become H7liJRPW-JGcYJrP9-picture.jpg, and the new smaller image sizes would be named things like vWCdtas2-JGcYJrP9-picture-100x100.jpg. After another round of regeneration that file would become say, 2jLL72he-H7liJRPW-JGcYJrP9-picture-100x100.jpg, etc.

4. I would like to truncate the uploaded filenames to 50 characters max. I don't think I mentioned this previously, I was going to do it myself with substr($whatever, 0, 50) but I'm having trouble (it works fine for the original and -scaled images but when I try it on the smaller sizes, it doesn't update their new filenames properly any more).

May I trouble you to help for a little longer? - By the way I don't know if this is frowned upon here but as you have been patient with me and your answers have been extremely detailed, do you per chance have a buymeacoffee.com or similar? You really deserve it!

Frankly, I don't need to put random characters at the start of the scaled versions - I really only need them on the original to ensure nobody can ever guess the URL. So I don't need to get that working perfectly. I do need to get those regeneration bugs ironed out though :( And I'd really love to be able to restrict the filename length.... users write whole novels in their filenames! >_<

Answer 1

Where am I going wrong?

Actually, your code is just fine.

Except that I would simply use wp_generate_password() to generate the random string. :)

WordPress will still think that the scaled version is called painting-scaled.jpg , etc. Resulting in broken images.

Yes, that's correct.

Images are stored as posts of the attachment type in the WordPress posts table (in the database), and the details (width, height, full file path, etc.) of the main image and its intermediate sizes (e.g. thumbnail and medium) are stored in a (private) meta named _wp_attachment_metadata — see wp_generate_attachment_metadata() and wp_get_attachment_metadata() for more info, but the meta value basically consists of:

• 'width' (int) The width of the attachment.
• 'height' (int) The height of the attachment.
• 'file' (string) The file path relative to wp-content/uploads.
• 'sizes' (array) Keys are size slugs, each value is an array containing 'file', 'width', 'height', and 'mime-type'.
• 'image_meta' (array) Image metadata.

And as for the -scaled version, if available, it will be used with the file item above and there'll be an additional item named original_image added to the above meta where the item's value will be the path to the originally uploaded image file — see wp_get_original_image_path().

So because the image_make_intermediate_size filters are applied both when generating the -scaled version and the intermediate sizes, then the -scaled version also gets renamed by your custom filter (the rename_intermediates() function), but unlike the above sizes item, WordPress no longer updates the file item once it is set after the -scaled version is generated.

Therefore that resulted in the broken image for the -scaled version.

But don't fret, there's a solution. 🙂

Yes, and basically you just need to use a different hook: wp_generate_attachment_metadata.

So just remove your image_make_intermediate_size filter and use the code below, and just let me know if you need any clarification:

// *UPDATED Feb 27th 2021 UTC

// Renames a file and if it succeeded, returns an array with the first item being the new name
// (e.g. <random string>-my-image.jpg). And this function is intended to be used only with the
// my_rename_images() below.
function my_rename_image( $file, $_rand_str = '' ) {
    $info = pathinfo( $file );

    $rand_str = wp_generate_password( 8, false ); // false = do not use special chars
    $new_name = $rand_str . '-' . ( $_rand_str ?
        str_replace( "{$_rand_str}-", '', $info['basename'] ) : $info['basename'] );
    $new_file = $info['dirname'] . '/' . $new_name;

    return rename( $file, $new_file ) ? array( $new_name, $rand_str ) : false;
}

// Note: The _main_rand_str meta is used to prevent re-adding the random string to the name of
// the renamed image files.
add_filter( 'wp_generate_attachment_metadata', 'my_rename_images', 10, 3 );
function my_rename_images( $metadata, $attachment_id, $context ) {
    // Do nothing if the attachment is NOT an image, or if the attachment wasn't being
    // created.
    if ( 'create' !== $context || empty( $metadata['image_meta'] ) ) {
        return $metadata;
    }

    $file = get_attached_file( $attachment_id );
    $_rand_str = get_post_meta( $attachment_id, '_main_rand_str', true );

    if ( $arr = my_rename_image( $file, $_rand_str ) ) {
        $metadata['file'] = dirname( $metadata['file'] ) . '/' . $arr[0];
        update_attached_file( $attachment_id, $metadata['file'] );
        update_post_meta( $attachment_id, '_main_rand_str', $arr[1] );
    }

    $dir = dirname( $file );
    foreach ( $metadata['sizes'] as $size => $data ) {
        if ( $arr = my_rename_image( $dir . '/' . $data['file'], $_rand_str ) ) {
            $metadata['sizes'][ $size ]['file'] = $arr[0];
        }
    }

    if ( ! empty( $metadata['original_image'] ) ) {
        $file = $dir . '/' . $metadata['original_image'];
        if ( $arr = my_rename_image( $file, $_rand_str ) ) {
            $metadata['original_image'] = $arr[0];
            update_post_meta( $attachment_id, '_main_rand_str', $arr[1] );
        }
    }

    return $metadata;
}

Sample output

So I uploaded a hi-res JPEG image via the Media → Add New admin page, and the generated file names/sizes are:

| File Name                             | Size Name      | Note                    | 
|---------------------------------------|----------------|-------------------------| 
| 768O4Y7q-foo-bar-image-scaled.jpg     |                | The "-scaled" version   | 
| zDQdlxMK-foo-bar-image-300x200.jpg    | medium         |                         | 
| 6CT8XZGI-foo-bar-image-1024x683.jpg   | large          |                         | 
| BFcUGvP8-foo-bar-image-150x150.jpg    | thumbnail      |                         | 
| 2vATG8xN-foo-bar-image-768x512.jpg    | medium_large   |                         | 
| 8xjeou4f-foo-bar-image-1536x1024.jpg  | 1536x1536      |                         | 
| 59YJJsQF-foo-bar-image-2048x1366.jpg  | 2048x2048      |                         | 
| 6HjAlOnr-foo-bar-image-1568x1046.jpg  | post-thumbnail |                         | 
| XQTkPM7I-foo-bar-image.jpg            |                | Original, but renamed   | 

UPDATE

In response to "Edit 27th Feb 2021" in the question:

1. "The new smaller size locations aren't all being updated" — this didn't seem to have happened in my case, so please try the updated code above and see if the issue persists.

2. "Image regeneration doesn't delete the old generated smaller sizes." — yes, because as you quoted it yourself, WordPress core says, "it does not check or delete intermediate sizes it previously created for the same image".

   So I'm afraid you'll need to either manually delete the existing intermediate sizes, or find a plugin which can help you delete them. But note that one good reason why WordPress doesn't delete the intermediate sizes, is because those images might be in use in that they were linked to from somewhere (which is not a thief..), so simply deleting the images is not a good idea.

3. Sorry about the random string which got re-added to the name of the renamed files.. But I've corrected it in the updated code above.