Media privacy and direct file URLs

Omeka S Modules
1

Hi Omeka S community,

We recently had an unexpected situation on our Omeka S installation and I am trying to understand whether this is expected behaviour.

One of our researchers had previously been experimenting with Omeka S and created a private site. While searching Google for a citation to a journal article, they were surprised to find a result pointing directly to a media file on our Omeka S server (e.g. https://servername/files/original/...). The file was one they had uploaded while testing the site.

At the time this was discovered, the site itself was private. As far as we know, the site had not been made public, although I cannot confirm whether the associated item or media record had ever been public or private during its lifetime.

My initial testing suggests that making a site, item, or media private does not prevent direct access to the underlying file if someone already knows its URL. In other words, the Omeka permissions appear to prevent discovery through the application, but not necessarily access to the file itself via its direct path.

I am therefore trying to determine whether:

  • the site, item, or media may have been public briefly at some point, allowing search engine crawlers to index the file; or
  • direct file URLs are always publicly accessible by design, regardless of the visibility of the associated site, item, or media.

This also reminded me of another behaviour we have noticed. If you know the numeric ID of an item, you can replace the slug in a site URL with that ID and the item will still be displayed, even if the slug belongs to a different site. I appreciate this is a separate issue, but it seems to point to a broader question about how Omeka handles direct resource access versus site-level visibility.

I have seen previous discussions recommending that sites, items, and media all remain private until they are ready for publication. I am wondering whether there are additional approaches to prevent search engines from indexing or accessing files directly, for example by restricting access to the file store unless requests come through Omeka itself.

Has anyone encountered this before, or are there recommended best practices for preventing this kind of exposure?

Thank you.

2 Likes
3

Yeah, the files are on the filesystem so they’re accessible if their name is known.

There isn’t a design or intention that the URLs for private media are accessible, and I’m not aware of a route where they are. Any such availability for private media, if it exists, would be a bug.

My best guess is also that this just was previously public at some point and indexed then.

Omeka S has a pluggable storage system so files can be stored in different ways and this could be used to make files that are not accessible at all without permission. This could be done with external hosting like S3 using their permissions system and pre-signed URLs, or locally with file URLs going through a frontend that pulls them from some otherwise-inaccessible location. I don’t know what the landscape looks like in terms of what options for doing this already exist, though.

1 Like
4

Hi Sanjin

we had a similar issue before where we had media that wasn’t supposed to be available publicly before the launch. In that case I put a basic authentication on that folder via Apache (see also Authentication and Authorization - Apache HTTP Server Version 2.4). So something like:

<Location <path-to-where-media-is-saved>>
        AuthType Basic
        AuthName "Restricted Access"
        AuthUserFile "<path-to-auth-user-file>"
        Require user <auth-user>
</Location>

It’s a bit annoying then that you have to provide a password every now and then during development, but it is simple enough to prevent unwanted access.
But I was also wondering what I would do if not all media from the media folder should be accessible.

5

I’m not sure if it would work for your particular usecase, but there is the Access Module, which works well for us for managing Embargoed/copyrighted items. It did take some tooling around with Apache to get it working properly, so be prepared to invest some time into setup