Page MenuHomeWrite.as

Support storing images and other files locally
Open, Needs TriagePublic

Description

Overview

Admins should be able to choose to store images locally on their server.

Implementation

First thoughts:

  • Create a new top-level empty directory in the project: media
  • Uploaded files should be stored here
  • Add an application handler that respects the Private config setting, and serves files from this directory
    • If private = false, always serve file from this directory
    • If private = true, only serve file if user is currently authenticated (whether via cookie or Authorization header (token))
  • Additionally, we might store a bit of metadata in a new database table:
    • filename - the uploaded file's name
    • owner_id - ID of the user who uploaded the file (could enable moderation, and full data removal when an account is deleted)
    • created - time and date the file was uploaded (could be used for enforcing per-time-interval restrictions)
    • size - the size of the file (could be used for enforcing data quotas, and reports for admins)

Event Timeline

What could be the better way to store uploaded images?

  1. Upload to folder which is publically accessible (exposed by nginx or Apache);
  2. Upload to private folder (only accessible by user which WriteFreely runs on) and have an endpoint to read image file and output it to the public?

Both has their pros and cons:

  1. Images on HTTP-accessible folder does not put any additional load on the server to process;
  2. Images on private folder can be as-is in their original form while publically shown image could be transformed: resized, watermarked, etc.

@gytisrepecka I think we'll want to go with option #1, so we can factor in instance privacy settings, and have totally private media files if an admin wants it. I just updated the description with some ideas I have for the very first version of this.

matt renamed this task from Support storing images locally to Support storing images and other files locally.Jan 31 2020, 1:44 PM

There are a few deeper issues to discuss that aren't part of this task:

File privacy on a Private or Password-protected collection on a multi-user instance. This could involve collections "owning" media files, which would mean locking media files to individual collections, and then updating ownership as the user moves a post between collections (or to draft). Because of the rigidity and complexity this would introduce, it's worth skipping for now.

File privacy on single-user instances. This leads to a larger conversation about the private config value, and how it relates to the collection visibility setting when there's only a single user / collection on an instance. We'll address this eventually, but to accomplish this particular task it's not important.