Add Restricted Access to Media Library

[shooper]

I've had many WordPress site owners who've e-mailed in a panic when they discover that a PDF, Word Doc, Spreadsheet, etc. they've uploaded in the Media Library has been discovered on Google with information that wasn't intended to be public. They thought that because the post or page that it was linked to was restricted, so what the media within.

The solution to this (for me) as been to move these files into a new folder, restrict it with .htaccess, and then have a PHP handler that checks for the appropriate permissions before passing the file content back to the browser.

Given I've run across this problem multiple times (with a relatively small customer base) I'd like to propose that the Media Library incorporate functionality to handle this in core.

1. Add a checkbox on media upload "Restrict Access to this media"

2. Media with that checkbox check would be uploaded into a wp-content/uploads/restricted/ tree (could still use the year/month/ subfolders).

3. Set .htaccess to restrict access to anything in that tree of folders.

4. (Haven't fully thought through this part), but create a permalink structure for accessing these resources that would be passed through the PHP engine.

If not, the media library / upload UI should have a clear warning about the accessibility to/discoverability of files uploaded, as I'm finding most users are caught completely off guard by this.

Interested in your thoughts...

[webdevmattcrom]

Great suggestion. Would make a lot of things much easier. Potentially this could even become useful for paid products, and zip files could be stored there and accessed from a user link more dynamically and securely.

[nutsandboltsmedia]

I think this is an amazing idea and one that would prevent a lot of headaches for users. There are so many ways this could be used, especially if we want WP to be seen as "more than just blogging." +1

[spanda]

So very needed.

[michaelbeil]

I think this could be an excellent addition to core.

[tvcnet]

Makes perfect sense for media to have protective options like pages and posts.

[netweb]

Thanks for creating the ticket @shooper, though this ticket is a duplicate of #17255

Also, you can just click "Watch this ticket" on that ticket to subscribe to further updates.

[shawfactor]

There is no need for checkboxes. Just enable users to select the status of attachment objects (currently it is always inherit).

If selected the selected status should dictate visibility, if not selected inherit would be the default (in which case the logic should be based on the attachments parent object).

[webdevmattcrom]

@netweb I disagree that this is a duplicate of #17255. The ideas that Nacin and Scribu brought up in that ticket (and #17254) seem to just be extensions of post statuses and how you don't want media "live" if the post itself isn't live, and potentially how media might inherit capabilities by user. While this ticket addresses similar weakness of the current Media Library and these two tickets would need to collaborate in order to be fleshed out, it's a bit hasty to say it's a duplicate and close.

The biggest difference @shooper's suggestion contributes is having a separate folder for completely restricted media. His example regarding PDF's is particularly useful for businesses that deal with a lot of "white paper" and don't necessarily want those live.

Please reconsider closing this until there's more discussion. (I know I can do that myself, but I'd rather get your input first).

[shooper]

@netweb I agree with @webdevmattcrom, although there is some overlap in the ticket you referenced in the duplication, these really are separate issues.

In #17255, once an attachment is set to "published", it is no different than what is in core today. If you know the URL to the content, you're still able to access it. My suggestion would force this to go through WordPress authentication first, pulling the file from a folder inaccessible directly via the web server.

[nacin]

This reminds me of ​https://wordpress.org/plugins/wp-document-revisions/. Note specifically how it handles private attachments: It moves things out of the web root if you can, and short of that, it hashes files to keep them private.

I don't really love the idea of trying to guard it via a rewrite rule, as it's too easy for that to fail.

[shooper]

@nacin Fair argument re using re-write rules to guard the files. Although we would need some method to run the file request through the WP authentication engine and then stream the file contents from the restricted location on the file system.

The idea of still keeping the files in the web root and guarded with an .htaccess file was in order to make this work consistently with a standard WordPress install. I'm making an assumption that installing files outside of web root is not supported by all hosts, and would also not get included in backups done by most WP backup plugins.

[jfarsen]

From a client's perspective (and even to me, to an extent), it would be expected that if you 'protect' a post from the public eye, than all the content would be protected : no difference between the copy on the page, and the attachments and media files included.

As to the "how", I have to think that patterns are already available (pattern libraries, previous art) on which we could base this on, to provide a UI/UX that's intuitive.

[shooper]

@jfarsen Agreed, this is definitely the way users intuitively understand post/page protection. The reason I'm suggesting adding this at the media level is handle media uploaded through the media library, not through attaching it to a post.

I intentionally left restriction control at the media level, so that the same object could be associated with multiple posts/pages that have a combination of protection levels. Use case: Protected Page with resources for registered users could include links to a video, image, PDF that is also available on public website, but included for completeness / ease of discovery.

[helen]

A thing to consider when it comes to attachment status as related to the parent post status (not the only case being discussed here, I'm aware): the risk of time out with many attachments is high, given things like filesystem access if using that method or transitioning post status for multiple items on post save and any number of things that could be hooked into that process.

[nacin]

I think using hashes for filenames is probably a better implementation for core, as it's flexible, won't suddenly make things appear due to .htaccess problems (or a migration of the WordPress site), and makes it easy for URLs to still be shared. It's a similar model that a lot of cloud hosting services use along the lines of CloudApp, CloudUp, etc.

That said, I'm not really convinced that any of these are core material. Is there a plugin that implements this in a simple and straightforward way?

[peterwilsoncc]

Replying to nacin:

That said, I'm not really convinced that any of these are core material. Is there a plugin that implements this in a simple and straightforward way?

​Media vault is in the repo (I haven't used it, looks straight forward) for protecting files.

I am -1 on this too, it's not a common enough use-case to warrant an instance of WordPress for each download.