Added check to see if disk implements a default visibility #164
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.
If you have "block all public access" enabled for an S3 bucket, then when uploading files you need to specify
'visibility' => 'private'
, you can currently do this for media items by adding:To your filesystem config for s3.
However the FileUpload widget does not respect the config. This change first checks if
visibility
is defined in the disk's config, falling back to the defaultpublic
if not.So the ACL is defined by the visibility that is passed to put here:
storm/src/Database/Attach/File.php
Line 1011 in f4c61a9
It falls through a bunch of stuff and ends up defining the object ACL here:
However, if you have block all public access enabled and have Bucket owner enforced enabled (the aws recommended option), then when uploading a file you get:
This is because AWS does not allow the writer to create public visible objects when block public access is enabled.
To fix this, you need to set visibility to private (although, actually setting it to anything !== public works), see:
In theory, the PR should:
$this->isPublic() ? ($this->getDisk()->getConfig()['visibility'] ?? 'public') : null
There'll be no change to existing functionality if people are not configuring the disk's visibility, and if they do it'll treat it as the default instead of defaulting to public.
If somebody (like me) is blocking public access, then they need to configure their bucket correctly to manage access to protected files, but that's done via bucket policies, Winter still needs to know to generate temp urls for objects, but the actual visibility is not massively important.