Add config to disable ACL in fog storage #2709
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
AWS S3 used to use ACLs to control access to files. In recent times, AWS has moved away from this complicated permission model to one backed by the much-more-complicated (but widely used) IAM permission model. ACLs are now recommended against, and in fact new buckets created since April 2023 will have ACLs disabled by default.
This means that any upload to a newly-created bucket, and any upload to old buckets that have had ACLs disabled, will now fail with an error if the upload specifies an ACL.
CarrierWave always specifies an ACL.
Solution
Add a way to just not supply an ACL in the form of
config.fog_acl = false
. Since current versions of CarrierWave always specify an ACL, the default has been set totrue
to maintain backward compatibility, but since AWS now defaults to no ACL, theREADME
has this value set tofalse
.Fixes #2664.
👀 I'm not familiar with Google's storage offering, but it appears they are in the same position according to #2634. However, I'm not sure if simply not setting Fog's
public
value is the right solution. If anyone who know's Google product can confirm, that'd be bananas.Attribution
I started with #2666. (Thank you @jalkoby!) However, it didn't cover every scenario. Please let me know if I should be doing something different to maintain attribution.