Derivatives of restricted items shouldn't be publically accessible

[seth-shaw-unlv]

I enabled permissions_by_entity (part of permissions_by_term) and created a "Staff Only" term in the "Islandora Access" vocabulary with fcrepo and Authenticated roles selected. I then uploaded a File with the "Staff Only" term. This worked as expected, authenticated users had access but Anonymous users did not.

However, derivatives generated for the item which, theoretically, should also be restricted were publically accessible. I see two possible solutions for this at first glance:

1. Have derivatives inherit the same permissions as the original file, OR
2. Don't generate derivatives for restricted content at all.

Other options?

[mjordan]

You can detect if a media has a term using a Context condition (see bottom of https://islandora-claw.github.io/CLAW/user-documentation/context/), so if you can assign terms as a Context reaction, we might be able to ship a preconfigured Context to handle this.

[seth-shaw-unlv]

@mjordan, so to make this preconfigured we would have to:

1. Generalize our existing 'Node has term' condition to be 'Entity has term'
2. Add at least one term to the Islandora Access vocabulary
3. Configure the 'image_original_file' context to use the new/updated condition and access term.

We should probably do the first one (although probably too late for 1.0) and the other two can be handled by documentation.

[seth-shaw-unlv]

Pft...whoops. I was looking at the list of available conditions by clicking 'add condition'. That list doesn't include the conditions you are already using. I completely missed the existing media has term condition with the original file term which I can add the new access term.

So, yeah, we only need to add a default term and update the default config. Still probably best done in documentation or as a submodule (although I've had trouble getting submodules to update existing configs).

[seth-shaw-unlv]

Actually, the inability to add multiple of the same type of condition is problematic for this use case. I would want to add a second media_has_term condition with the 'Staff Only' term that was negated while the original condition is not, but the UI isn't allowing me to do that.

The only way to do it now is to also create an 'Anonymous' access term which would be applied to everything except those with 'Staff Only' access and use the anonymous term in the condition.

We could update the condition to allow each term to be negated or not...

[mjordan]

Is there a hook that fires when derivatives are created? If so, we could implement it to assign the tags to all derivatives.

[kayakr]

@seth-shaw-unlv We're using a simple access control mechanism of Media being published/unpublished along with Drupal private files. Any solution using Drupal public file system doesn't stop derivatives being served by the webserver...

[mjordan]

@kayakr When I configure a term using Permission by Term module to be accessible to have content tagged with it only accessible to specific roles, for example, with this configuration on my term "Private stuff":

And then add that tag to a media entity, going to either the media's URL (http://localhost:8000/media/100) or the associated file's direct URL on the public filesystem (in this case, http://localhost:8000/_flysystem/fedora/csv_migration/Free%20Smells.jpg) as an anonymous user results in an "Access Denied" response. Toggling Anonymous on and off in the term permissions configuration results in predictable access restrictions on that file.

Am I missing some way of testing this so that an unauthorized user can access that restricted file?

[mjordan]

Related issue and discussion is #823.

[seth-shaw-unlv]

@mjordan files that use the "public://" filesystem descriptor cannot be restricted using Drupal access control mechanisms as they are served directly be the webserver. Files using the "private://" or any Flysystem-based descriptor (such as our "fedora://") can.

@kayakr, it is simple enough to point derivatives at the private filesystem (although this adds system overhead that most of my content doesn't need). How are you determining which published/unpublished status a file should have? In most cases I want my derivatives to be open immediately; it is only the restricted content (a relatively small percentage) that shouldn't be open.

[kayakr]

@mjordan The explanation from @seth-shaw-unlv is my understanding also; the term might restrict access to the original file on fcrepo via flysystem, but if the derivatives are in Drupal public:// then they can be reached anonymously as Drupal isn't involved in serving them.

@seth-shaw-unlv At the moment content is ingested and defaults to unpublished, including derivative media. They can be bulk-selected in Admin UI and changed to published. We haven't set up any smarter actions about toggling a Repository Item node and all related media to published/unpublished, but that would be nice.
We haven't yet looked at moving files from private:// to public:// when published, though I have done that on D7.

[mjordan]

@kayakr and @seth-shaw-unlv OK, sorry, I mistakenly thought I had my thumbnail generation configured as per #1037.

[kayakr]

@mjordan @seth-shaw-unlv FYI, we've been using https://www.drupal.org/project/file_access_fix to move files between private and public storage based on media status published or unpublished. Our default filesystem is Drupal private, so original files go to fedora via flysystem, then derivatives are private unless published, in which case file_access_fix moves them to public and they can be cached via varnish et al.