Closed (fixed)
Project:
FileGate
Version:
1.0.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Sep 2026 at 05:41 UTC
Updated:
3 Oct 2026 at 14:10 UTC
Jump to comment: Most recent
Problem/Motivation
A field storage marked as gated on a public file scheme is this module's worst state: the configuration says the files are protected and the web server hands them to anyone with the URL.
Two checks exist. The field storage form forces the private scheme, and GatedFieldSchemeValidator rejects the combination at config import. Neither runs when a field storage is saved any other way: a config API write, a Drush config:set, a recipe, an update hook, or a governed configuration tool over MCP. Those writes succeed, and the only trace is a status report error afterwards.
Steps to reproduce
- Take a file field whose storage uses the public scheme.
- Set the
file_gatethird-party settinggatedto TRUE on its storage withdrush config:setor the config API, and save. - The save succeeds. Files stay public. The status report then shows the error.
Found by reading 1.x. Not yet reproduced on a site.
Proposed resolution
- Reject the combination at save, not only at import: a presave check on
field_storage_configthat throws whengatedis TRUE and the storage has auri_schemeother thanprivate. It covers every write path, including the form and the import. - Express the same rule as a constraint in the config schema for the third-party settings, so validating callers get a violation with a property path before the save.
- Keep the status report finding for sites that are already in this state.
- Do not change how an existing site in this state loads or edits the field; only a save that would create or keep the combination is refused, with a message that says how to fix it.
Remaining tasks
- Kernel tests: config API save refused, form save still works, import still refused, a field type with no
uri_schemeunaffected, switching an already gated storage from private to public refused.
API changes
A save that used to succeed and leave files public now throws.
Comments
Comment #2
jmcerdaCommitted to 1.x; ships in 1.10.0. One rule class now backs every guard. A presave hook on the field storage entity throws before any write. A config save subscriber covers raw config writes such as
drush config:setand governed config tools: core has no event before a raw write, so it restores the previous value and then throws. The import validator and the status report use the same rule, and a schema constraint lets validating callers see the violation with a property path. Only a save that creates or changes the combination is refused. Refusing every re-save of a storage that is already in this state would break core updates, uninstall and the field form on affected sites, so that case stays a status report error. Refusals are written to the audit log. The work also caught a regression in its own first draft, where a public field that already holds files could have been gated through the form; that is covered by a test.