Media File Restriction Just Doesn’t Work

  • tonydjukic

    (@tonydjukic)


    2 years, 10 months ago

    Before I get into the issue I’m attempting to address I do have to say that the support page that people keep getting told to visit doesn’t actually offer any support avenues. The contact form on the AAM site explicitly states that support questions shouldn’t be submitted there and then sends you back to the same support page that doesn’t give any options for support. There’s some FAQs and the Knowledge Base, but what does one do if following a Knowledge Base article is what has resulted in the need for support?

    That said:

    https://aamplugin.com/article/how-to-manage-access-to-the-wordpress-media-library

    Followed the procedure for NGINX servers and configured AAM as instructed.

    Initially, this broke the site as other plugins were writing custom CSS to files in uploads (MegaMenu) and those files became inaccessible.

    All images, assets, etc. were unable to load not just for anonymous visitors, but for all users, regardless of how we configured AAM’s global rules. We wanted to restricted media file access to all anonymous users, but grant access to all ‘logged in users’.

    What we got was either ‘everything is restricted for everyone all the time and the site breaks’ or ‘nothing is ever restricted at all’.

    What we’re after, or rather what we’ve settled on, is restricting access to PDFs, MP3s, MP4s, MOVs, XLSX and XLS files. We have re-applied the NGINX configuration but narrowed the scope of what is being restricted. We have configured the global settings and then attempted to restrict individual media files (of the types listed above) for anonymous users.

    Unfortunately, anonymous users can still access the files directly.

    What do we need to do to make this all work?

    This is the NGINX configuration:

    location ~* /wp-content/uploads/ {
rewrite (?i)/wp-content/uploads/.pdf$ /index.php?aam-media=$1 last;
rewrite (?i)/wp-content/uploads/.mp3$ /index.php?aam-media=$1 last;
rewrite (?i)/wp-content/uploads/.mov$ /index.php?aam-media=$1 last;
rewrite (?i)/wp-content/uploads/.mp4$ /index.php?aam-media=$1 last;
rewrite (?i)/wp-content/uploads/.xlsx$ /index.php?aam-media=$1 last;
rewrite (?i)/wp-content/uploads/.xls$ /index.php?aam-media=$1 last;
}
Viewing 3 replies - 1 through 3 (of 3 total)
  • Alan Upstone

    (@alanupstone)

    2 years, 10 months ago

    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.

    Thread Starter tonydjukic

    (@tonydjukic)

    2 years, 9 months ago

    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!

    Alan Upstone

    (@alanupstone)

    2 years, 9 months ago

    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.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Media File Restriction Just Doesn’t Work’ is closed to new replies.