- 最新
- 投票最多
- 评论最多
Apparently, the issue was from how i was naming the object in the bucket. I added a timestamp in ISO8601 format to each objects' name when creating the s3 presignedUrl for the PUT request. So when cloudfront tries to access it, it changes the some of those weird characters in the date string, and as a result, s3 denies access. Because the object cloudfront is trying to access doesn't exist. Thanks for the help
If I understand correctly, from the same bucket and using the same cloudfront distribution, you were able to get objects you uploaded in console, but not the objects you PUT through pre-signed URLs generated using SDK? If that's the case, you may want to check 1. Is the client generating the URLs under the same account as the bucket owner 2. You are not specifying KMS encryption in generating the URL 3. Are you setting any ACLs using header or querystring in PUT request? You can verify by checking the SSE and Permission (Owner/ACL) of the objects you got Access Denied.
Assuming that your use-case is to securely fetch the S3 objects. You first need to get the pre-signed URL and then use that pre-signed URL to fetch the S3 object. One common way is to use an API endpoint (backed by a lambda function) that returns the pre-signed URL generated for the S3 object you want to read. Then you'd use that pre-signed URL in your client to actually fetch the S3 object. Hope I answered your question.
@Venkat_Gomatham I don't have issues generating and fetching s3 objects using the s3 pre-signed URLs. The issue i have is fetching the object using cloudfronts signed URL. The flow is, I get a pre-signed URL using the s3 sdk, i use that URL to PUT an object into s3 (that works fine). But when i want to GET that object back, i don't want to use s3 pre-signed URLs anymore for that, i want to GET the object back using cloudfront, to be more precise, cloudfront signed URLs
@Bo_G Yes, I am pretty new to aws. But from what i understand, the client is generating the URL under the same account as the bucket owner, if it wasn't i wouldn't be able to access the objects uploaded via the s3 console from the client. Since it works for that case, i dont think thats the issue. I don't know anything about KMS encryptions, but according to the documentation i used, all i needed was a key pair id for a RSA public key i provided to aws and the RSA private key. Those were supplied to generate the URL I am not setting any ACLs on my PUT request, ACLs are disabled on my bucket. I went ahead to check the permissions of the object i got denied from, and only the object owner has read/write priviledges.
If you compare the objects that you got access denied with the objects you uploaded from console and were able to get through Cloudfront, check the Properties -> Server-Side Encryption Settings, then compare the Permission / ACL / Object Owner canonical ID, are they all the same?