Media File Restriction Just Doesn’t Work

I have had similar problems. I can get it to work on a local site running nginx, but not on the live remote site hosted by flywheel.

We found that everything, including CSS, was getting blocked. With help from Flywheel support, we are getting a more precise redirect. In our case, we just want to affect PDFs with ‘ssp’ in their filenames.

#rewrites for AAM plugin
location ~* ^/wp-content/uploads/.*ssp.*\.pdf {
rewrite (?i)^(/wp-content/uploads/.*)$ /index.php?aam-media=$1 last;
return 307;
}

Note that we have an escape (\) before the file extension, i.e. \.pdf rather than just .pdf because the thumbnails generated by WordPress for the media list dashboard page for the PDFs were getting clobbered too.

A similar rewrite might work for you. I think you’d need some sort of wildcard before the .pdf in your re-write or it will just match files called .pdf – maybe .*\.pdf would work.

We are still finding that the rewrite to index.php?aam-media=sss-file.pdf is not working on nginx. It just doesn’t seem to like the aam-media query string and we get a 403 error. I note that the developer fixed an nginx bug at the last commit to v5 (in v.9.7.1). I wonder if that bug sneaked back into v6?

I submitted a help request to aamplugin.com but was told I was in position 302 and might be prioritised below people after me. Perhaps understandable given the low cost of the plugin. I’ll post an update either I get a reply.

It’s also not entirely clear if the AAM Protected Media Files plugin we have is redundant if we have the AAM plus package. Activated or deactivated does not seem to make any difference.

We tried a direct approach with https://example.com/index.php?aam-media=ssp-demo.pdf and that 403s too.

Oddly enough, I’m working with FlyWheel on this as well…

…it’s just NOT giving us the desired results. Whatever we try, one thing works, but then the another doesn’t. It’s listed as a simple solution in the documentation but has proven to be anything but.

I’ve actually just come up with a different method I think will work. ManageWP.com has the ability to still access sites that have HTTP Authentication enabled on them. You provide the username and password and it’ll auto login when it contacts the site to check it for updates, etc.

That gave me the idea of adding directories and using HTTP Authentication on them, then writing a script that will automatically pass credentials to the HTTP Auth dialogue without the user ever knowing. So files that need to be restricted are instead uploaded to the HTTP Auth protected directories and then all the user has to do is add a ‘class name’ to links to any of those files when they post them to the site. Then you’d use the standard is_current_user() to load the script. If they don’t have the right user role or aren’t logged in, the script just doesn’t get enqueued.

For starters I’m just going to FTP the PDFs and other files into the restricted directories. But eventually the whole thing can be made entirely seamless within WordPress. I can add a toggle to the media upload process that if checked will know to upload the file to a different directory (have done this for some front end image uploading on a membership site), then I can make a custom Gutenberg block that already had the class assigned to it that the auto login script depends on. There’s really a ton of options when you’re doing it all yourself.

Using the plugin wasn’t something I would have done but I’ve inherited this project from another agency.

I’ll pass your NGINX items over to FlyWheel and see if that makes a difference though, but in earnest, I’m kinda over fighting with this plugin and figuring out how to get support. Lol!

Thanks for taking the time to reply, Tony. My Flywheel support ticket is 14516689 and it might help them ‘join the dots’ to know it is a problem for more than one of us.
I was dreaming about a similar solution to yours then got up and read your post. I think Vasyl, the plugin creator, is a genuine chap and the plugins works well for us for role capability management. However, I have found by exporting and reading the AAM settings file that the things one does in the interface do not always get saved/deleted properly in the settings file. Sometimes I can edit that file and import it to cure the problem.

I can get it to work on the local version, just not on Flywheel. The redirect happens, but the query string in /index.php?aam-media doesn’t seem to be recognised. I am going to try reinstalling the plugin.

I also note that Flywheel add a line to the re-write, apparently for their platform’s needs.

#rewrites for AAM plugin
location ~* ^/wp-content/uploads/.*ssp.*\.pdf {
   rewrite (?i)^(/wp-content/uploads/.*)$ /index.php?aam-media=$1 last;
   <strong>include no-cache.conf;</strong>
   return 307;
}

It seems that other plugins also have problems with shared platforms too (https://preventdirectaccess.com/docs/flywheel-hosting-support/).

Would you care to contact me at https://www.helpfulconsultants.com/contact/ ? We can perhaps help each other.