Timeline for Randomise upload filenames (or another solution to hide the original image URL from theft?)
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2021 at 3:31 | history | edited | obinice | CC BY-SA 4.0 |
Edit 27th Feb 2021 in response to Sally CJ's answer
|
| Feb 27, 2021 at 3:24 | history | edited | obinice | CC BY-SA 4.0 |
Edit 27th Feb 2021 in response to Sally CJ's answer
|
| Feb 27, 2021 at 3:12 | history | edited | obinice | CC BY-SA 4.0 |
added 4 characters in body
|
| Feb 27, 2021 at 3:04 | history | edited | obinice | CC BY-SA 4.0 |
Edit 27th Feb 2021 in response to Sally CJ's answer
|
| Feb 25, 2021 at 0:39 | comment | added | Sally CJ | So did my answer help? Did the code work? If so, I'd appreciate it if you can mark my answer as correct (just tick the check-mark next to my answer) - doing so will help others know the question has an accepted solution. :) | |
| Feb 20, 2021 at 2:50 | answer | added | Sally CJ | timeline score: 1 | |
| Feb 18, 2021 at 17:53 | comment | added | obinice |
I think I have the REST API locked down, though I'm not deeply familiar so please correct me if I'm wrong. When I load up something like /wp-json/wp/v2/media, /wp-json/wp/v2/media?search=file.jpg, even as an admin, I'm greeted by {"code":"itsec_rest_api_access_restricted","message":"You do not have sufficient permission to access this endpoint. Access to REST API requests is restricted by iThemes Security settings.","data":{"status":401}}. Hmm... all I need to do at the end of the day is have the original filename be un-guessable. Can accomplish this? Or I must find another solution? :-(
|
|
| Feb 18, 2021 at 14:45 | comment | added | Sally CJ |
And just so you know, advanced users could easily check the REST API on your site (e.g. the default media/attachment endpoint at example.com/wp-json/wp/v2/media) and the original file names will be exposed by default (and I'm not referring to just the guid, but other fields like original_image). So instead of randomizing the file names, perhaps you can try looking for or using another option?..
|
|
| Feb 18, 2021 at 14:45 | comment | added | Sally CJ |
Thanks for the code and sorry! I think I didn't really pay attention to the "-scaled" version of the original (high-res) image.. I mean, you're right - and why the issue happens is because the scaled version also gets renamed, but it's a special entry in which WordPress updates its (meta)data before the intermediate sizes are created, but WordPress no longer updates the data afterwards even if the scaled version got a new path/name/etc. Therefore WordPress still using the old file name having "-scaled", e.g. /some/path/some-name-scaled.jpg.
|
|
| Feb 18, 2021 at 0:39 | comment | added | obinice | I've added the full thing to my original post @SallyCJ | |
| Feb 18, 2021 at 0:37 | history | edited | obinice | CC BY-SA 4.0 |
Added the second portion in full as per request.
|
| Feb 17, 2021 at 23:53 | comment | added | Sally CJ |
Yes, the original image is stored as an attachment post, and yes, its guid normally contains the URL of the original image file. But as for the scaled images, their details are saved in a metadata. And actually, I already tested your second code and it worked fine for me (i.e. no broken images), so how did you generate the random string? Can you show the actual part/code which fills the $randomString variable?
|
|
| Feb 17, 2021 at 15:50 | comment | added | obinice |
Just doing some research - Wordpress stores attachments as posts with the post_type of attachment, and the full URL of the original image is stored in guid. I don't see any information about how it stores the location of the scaled images though, I'm worried that perhaps it doesn't - and perhaps it always relies on extrapolating from the original image URL? If this is the case, I'm truly at a loss as to how I can ensure the URL of the original image is not guessable by the public & thus stealable :-(
|
|
| Feb 17, 2021 at 15:25 | comment | added | obinice | First off - I really appreciate your trying to help me out :-) Unfortunately just using the second filter on its own has the same problem. It successfully renames all the scaled images, but Wordpress has no idea what those filenames are - it blindly thinks they're the regular filenames that it would normally generate. I'm guessing I need to figure out how to adjust how Wordpress stores these filenames in its database when it generates them, so it remembers the correct modified filenames for all the sizes? That's currently a bit beyond my knowledge. | |
| Feb 17, 2021 at 9:30 | comment | added | Sally CJ |
Are you actually using both the first (sanitize_file_name) and second (image_make_intermediate_size) filters? You should use just the second - try removing the first and see if the issue persists? And do you also want to randomize the name of the original image?
|
|
| Feb 16, 2021 at 18:53 | comment | added | obinice |
@SallyCJ I'm using the normal WP Media library for this whole process. Using the latter method above to rename the scaled sizes, if I upload an image the scaled sizes are generated and named randomly e.g.: 5p1qntwy.jpg 1stykqpwq.jpg ..etc, and the original filename has the randomly generated characters inserted at the start, e.g.: b90a5NUv-IMG_9813.jpg WP gets the original file URL right, but gets the scaled image sizes wrong. It thinks the main scaled image is e.g.: b90a5NUv-IMG_9813-scaled.jpg But, the main scaled image is actually called 5p1qntwy.jpg.
|
|
| Feb 16, 2021 at 0:59 | comment | added | Sally CJ | Your code looks good to me, so are you sure that you're getting broken images? What code did you try when displaying the image? Could it be a caching issue (did you try clearing the site and your browser caches)? | |
| Feb 15, 2021 at 21:07 | review | First posts | |||
| Feb 15, 2021 at 22:09 | |||||
| Feb 15, 2021 at 20:57 | history | asked | obinice | CC BY-SA 4.0 |