Could someone elaborate a bit on the whole access level (public vs private) with Storage.put? Is this just a suggested convention we follow, or is it important to use because other elements of AWS Amplify will rely upon it?
My use case:
Users will upload audio files that belong to them (so other users should never access these), _but_ these audio files will be served up to the general public/unauthenticated users (so the S3 bucket policy will allow this).
So would it make sense to set the bucket policy so GetObject can be performed on arn:aws:s3:::my-bucket/private/*/audio-files/*? Or should users' audio files just be stored in /public?
Hi @ffxsam Thanks for your feedback
When you enable User file storage on AWSMobile, this bucket has a public/private/protected/uploads prefix. Currently Amplify handles public and private prefix.
On public prefix every user can upload/download/delete files
On private prefix every user will have another prefix (userid) and the bucket policy only allows to that user to read and write data on it.
On the use case you mention we could add on amplify support for protected permissions so each user that uploads the file can modify or delete and all other users can read from it.
That makes sense, I will discuss with the team on Monday meeting.
@elorzafe To be clear, I don't need other users to read each others' files (via S3 API). In fact that would be very bad. But each users' files would need to be accessible via HTTP (public bucket policy). My question is more about whether it makes sense to set a public bucket policy on /private or not.
@ffxsam In that case what I think it will be better if you host this files on the hosting bucket that also use CloudFront :)
I would try to transfer the files that end users uploads on user-files bucket to the hosting bucket, exists different mechanism to do that. I can discuss this with a Solution Architect to give you more information.
Well, then there would be just one bucket and it would be a hosting bucket. :) There are no files I'm storing that will always be 100% private. Everything the user uploads and works on in this application could potentially be shared via HTTP links.
I checked this blog, maybe this can help on your use case. https://aws.amazon.com/blogs/compute/synchronizing-amazon-s3-buckets-using-aws-step-functions/
Please feel free to continue discussion
Thanks!
These could potentially be several 50-150MB files per user (with potentially thousands of users), so I wouldn't want to replicate them to another bucket as it wouldn't be cost-effective.
Ok, so my only suggestion for Amplify is that it remains fairly open so that people can pick and choose which parts to use. I may wind up using my own storage conventions for S3, but I'd still want to use Auth which is massively helpful.
@ffxsam have you thought about using Auth with AppSync Complex Objects for this use case: https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app-react.html#complex-objects
Whoa! I didn鈥檛 even know about this, thanks for bringing it to my attention. I wonder how configurable this is. I need to upload to very specific folders and also set Content-Type on uploaded files.
Complex objects definitely needs more documentation.. it's not clear at all how this works. I'll open a new issue.
Following up - we have released a sample app showcasing this functionality here: https://github.com/aws-samples/aws-amplify-graphql
Can anyone demonstrate how private files can be accessed by any other user in any react or react native app.
Most helpful comment
Can anyone demonstrate how private files can be accessed by any other user in any react or react native app.