So there are two parts to accessing the S3Object, one from the bucket itself and two from the actual API. Typically the best security practice is to leave all images secure and only access them using a signed URL. The example I gave with private images is typically the use case I recommend. If we use @auth rules for owner, only the user uploading them image would be able to view it but in reality we want it to be available to any user of the app. Sure, we could set queries to null and allow anyone to access the location that of the image, but either way we ideally only want users accessing the image directly from our app to be successful.
We actually have equal support for Angular & Vue. We now also have an advocate like me on our team who specializes in angular but does not write as much content, he's busy traveling around giving more workshops and talks. I think we see much more articles talking about React because I am very visible and active in that community, but in reality there is pretty much feature parity between the frameworks.
I don't know the answer to this. If this is a feature you'd like, I'd suggest submitting an issue in the GitHub repo and we can see about putting it on our roadmap.
1 No, the @auth rules only apply to the GraphQL API not the S3 bucket for storage. The rules you mentioned will allow anyone to read from the database, but the a user still needs to be authorized to read from the S3 bucket in some way, either signed in or not, via the Amplify SDK (sends a signed request, gets a signed url that is valid for a set period of time)
5 You can update the API key by changing the expiration date in the local settings and run amplify push to update -> aws-amplify.github.io/docs/cli-too...
Yes you can combine authorization rules. See details here
Private access is built in to Amplify - See docs here referencing private access
Yes, the process of storing would be the same, the only difference is you would need to deal with standard streaming / buffering protocols on the client that are agnostic to Amplify.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So there are two parts to accessing the S3Object, one from the bucket itself and two from the actual API. Typically the best security practice is to leave all images secure and only access them using a signed URL. The example I gave with private images is typically the use case I recommend. If we use @auth rules for owner, only the user uploading them image would be able to view it but in reality we want it to be available to any user of the app. Sure, we could set queries to null and allow anyone to access the location that of the image, but either way we ideally only want users accessing the image directly from our app to be successful.
We actually have equal support for Angular & Vue. We now also have an advocate like me on our team who specializes in angular but does not write as much content, he's busy traveling around giving more workshops and talks. I think we see much more articles talking about React because I am very visible and active in that community, but in reality there is pretty much feature parity between the frameworks.
I don't know the answer to this. If this is a feature you'd like, I'd suggest submitting an issue in the GitHub repo and we can see about putting it on our roadmap.
1 No, the @auth rules only apply to the GraphQL API not the S3 bucket for storage. The rules you mentioned will allow anyone to read from the database, but the a user still needs to be authorized to read from the S3 bucket in some way, either signed in or not, via the Amplify SDK (sends a signed request, gets a signed url that is valid for a set period of time)
4 Yes, we support multi auth now (starting last week) from the CLI -> aws-amplify.github.io/docs/cli-too...
5 You can update the API key by changing the expiration date in the local settings and run
amplify pushto update -> aws-amplify.github.io/docs/cli-too...Yes you can combine authorization rules. See details here
Private access is built in to Amplify - See docs here referencing
privateaccessYes, the process of storing would be the same, the only difference is you would need to deal with standard streaming / buffering protocols on the client that are agnostic to Amplify.