Store protected assets outside of webroot

[chillu]

Overview

Split out from 4.1-level change to public webroot in #7419

Acceptance Criteria

• Protected assets can be placed outside of public/ webroot
• Opt-in through an environment constant
• Uploading and publishing assets moves them to the right folder
• Works gracefully if there is no public/ folder ("legacy mode")
• Migration can be documented as manual ("move public/assets/.protected to assets/)

Notes

• Likely too impactful for the 4.x release line, because of the amount of hosting environment adjustments
• Folder name to be determined (assets vs. public/assets might be too confusing?)
• Will need adjustment in our hosting platforms (SSP and CWP) regarding snapshots from two folders
• Will require users to consider which folders are webserver-writeable, and how to change their own backup/restore strategies

[sminnee]

Ideally we could allow for this in the 4.x release line by introducing separate config settings for public-asset-path, and protected-asset-path. By default, protected-asset-path = $publicAsssetPath . '/.protected' but it can be overridden.

I would recommend allowing the use of environment variables to specify these, so that a hosting environment can specify its set-up.

[tractorcow]

We do have SS_PROTECTED_ASSETS_PATH, which lets you set the protected path. It's not safely normalised though (you might need to use ../assets to break out of the public dir).

You can also inject it this way.

SilverStripe\Core\Injector\Injector:
  SilverStripe\Assets\Flysystem\ProtectedAdapter:
    class: SilverStripe\Assets\Flysystem\ProtectedAssetAdapter
    constructor:
      root: './assets' # note: path relative to base path, not public or assets. Could be anything really.

Probably needs to have better docs, migration tools (i.e. for moving paths around), and could be set as the default at some point in the near future.

[sminnee]

Cool, so this might simply be a matter of fully testing this use-case.

[chillu]

1. Create project (4.6.1 in my case)

composer create-project silverstripe/installer

2. Configure env (used Lando since it's easiest)

.env

SS_DATABASE_CLASS="MySQLPDODatabase"
SS_DATABASE_NAME="SS_mysite"
SS_DATABASE_SERVER="database"
SS_DATABASE_USERNAME="root"
SS_DATABASE_PASSWORD=""
SS_DEFAULT_ADMIN_PASSWORD="password"
SS_DEFAULT_ADMIN_USERNAME="admin"
SS_PROTECTED_ASSETS_PATH="../.protected/"

.lando.yml

name: my-project
recipe: lamp
config:
  webroot: public

proxy:
  appserver:
    - my-project.lndo.site

3. Start up project, build

lando start
lando exec vendor/bin/sake dev/build

4. Upload file in admin/assets

5. Observe the file structure (abbreviated)

tree -L 3 -a
├── .protected
│   ├── .htaccess
│   └── 29195f23bb
│       ├── DSC01398.jpg
│       ├── DSC01398__FitMaxWzM1MiwyNjRd.jpg
│       └── DSC01398__FitMaxWzYwLDYwXQ.jpg
├── public
│   ├── .htaccess
│   ├── _resources
│   │   ├── .htaccess
│   │   ├── .method
│   │   ├── themes
│   │   └── vendor
│   ├── assets
│   │   ├── .gitignore
│   │   ├── .htaccess
│   │   ├── error-404.html
│   │   ├── error-500.html
│   │   └── web.config
│   ├── index.php

6. Retrieve a protected file

There are no mechanisms for migrating from one configuration to another, although that should be pretty obvious to anyone who deals with files, right? It would only become our problem if we did this automatically for existing projects.

I've created a docs PR: #9736, and would say this closes this issue. While Lando is running nginx only, I can't see how this behaviour would be webserver dependant. Beyond requiring read access to that new folder location of course. Any further validation required?

[chillu]

Merged the docs PR, closing this issue.