Problem/Motivation

When access workflow is in place, the fixed public / private sorage configuration is a problem:

* If site owner chooses public file storage, they suffer from PSA-2016-003
* If site owner chooses private file storage, they suffer from performance penalty. For example, on a campaign page with 50ish
anonymous-user-submitted-and-reviewed testimonial photos, serving the page needs 51 Drupal bootstraps

Proposed resolution

See File access fix as contrib POC, its README and code.

Remaining tasks

* Consent on that we want this and get Subsystem(?) Maintainer signoff
* Roll a POC
* Add tests
* Remove the "Use public / private file storage" setting on file fields (this issue is about autodetecting that)
* Review, commit, profit

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

The "public / private file storage" setting on file fields has gone. Drupal autodetects this now.
If you as developer want to adjust this, you can swap out the service or implement some hooks.

Comments

geek.merlin aka axel.rutz created an issue. See original summary.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Assigned: geek-merlin » Unassigned
Issue summary: View changes
Issue tags: +Needs subsystem maintainer review
xjm’s picture

xjm
she/her
Primary language English
commented
Priority: Normal » Major
geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: Automatically move files to public / private storage, depending on containing entity access » Automatically move files to public / private storage, depending on referencing entities' access

Let's be prrrrrrecise.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

prudloff’s picture

prudloff commented

This would improve the security of the Drupal ecosystem.
Because of the performance cost of private files, a lot of websites use public files by default and sometimes involuntarily expose files.

Remove the "Use public / private file storage" setting on file fields (this issue is about autodetecting that)

I think we should keep allowing to force public or private file storage. There are use cases where having a predictable path for files is useful (for example if files are also manipulated by another system than Drupal). It can also be useful to force private files on public entities (to be able to alter the file response headers for example).
This new behavior could be a third option on file fields.

prudloff’s picture

prudloff commented

Is #1836080: Unpublished files should be in private storage a duplicate?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Status: Active » Closed (duplicate)
Related issues: +#1836080: Unpublished files should be in private storage

Yep, setting as dup.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.