CORS parameters not taken in account on OPTIONS calls to buckets with local names #258
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#258
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
OPTIONS
calls do not match local bucket names, since these requests are not authenticated.PR #254 implemented things this way: CORS parameters of a global bucket with the same name will overshadow CORS parameters of the bucket with the local name. If there is no bucket in the global namespace with that name, CORS headers that allow everything are returned, so as to not prevent us from developping web apps that makes use of local bucket aliases. (This only pertains to the
OPTIONS
call, all other calls to the S3 API are authenticated and proper CORS policies are taken into account even for local bucket names).Security notice: CORS cannot be relied for as a security measure for bucket with local aliases. Make sure you handle your S3 API keys properly, that's the only true way to secure access to the API.
Please comment here if you have a use case where the behavior of the
OPTIONS
call implemented in PR #254 is an actual issue.I'm not sure if this has something to do with it but I get a 'CORS Missing Allow Origin' error on my POST requests but paradoxically not for my OPTIONS requests, so:
OPTIONS ✅
POST ❌ 'CORS Missing Allow Origin'
My CORS rules set via AWS CLI are:
And the response I get for the pre-flight OPTIONS is:
But for the POST request which gets called right after that, is:
Am I missing somthing? I would really appreciate any help.