@trevorwood – So I’m gonna blame this on WordPress to some degree for the confusion.
We have some code that generates rules automatically for all WordPress content types (pages, posts, tags, categories, “media”) etc.
In this case media however isn’t the image or media file itself, its the WordPress database representation of that item, and in the old WP days, it had its own URL where you could see the media in a blog post format/template with comment form etc.
It was like every image in a blog post was also its own media post that could have meta.
That page is what you are selecting to restrict.
We have mentioned many times in support topics & reviews that this is currently not feasible due to the wide varieties of server infrastructure, technical limits and such that WordPress is served on.
To truly protect media files you have to do it at the server level, usually via .htaccess file or nginx config files.
These can’t be relibly written to on all servers.
Further the way it works is by redirecting from a public url to a tokenized url that your server then authenticates and either serves the media file or doesn’t.
The dilema there is every media file request now has to go to the server and load an entire instance of WordPress, query the DB and authenticate the user, then load the contents of the file into memory and send it as the response.
This means a user going to a page with 10 images, will make 11 or more requests to the server. That is not scalable with large amounts of concurrent traffic.
Because we know we can’t do it in a reliable way we are not currently entertaining the idea of adding it either. This plugin and a few others we have are meant to be simple solutions that just work without a ton of extra fluff.
That means it isn’t the best solution for all cases, but might be perfect for others.
Hope you get it worked out.
