-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow anonymous connections to the S3 cache backend #45
Comments
Hi Jesse!
Solutions I can think of:
|
Hey Peter! Yeah, I agree:
Perhaps another option might be to:
This shows my credentials if they are configured and shows no credentials if not. |
Hi Jesse, I believe pip-accel version 0.22 resolves your problem. I went with option two in the end because I realized this past weekend that if I want to allow people to use Boto's "automagic" support for the EC2 metadata service there is no way to avoid the HTTP request so I should just accept it and move on. Anyway, the EC2 metadata service uses the IP address Can you confirm whether pip-accel 0.22 resolves your problem? Thanks for the feature request! |
Peter - I think it seems to work, but with a few caveats.
We would probably catch these and any other corner case issues or bugs by writing unit tests for the S3CacheBackend. I could totally help do that if you'd like. |
This is now fixed: I silenced the Boto logger. There is an escape hatch in case someone ever does need to debug the usage of Boto inside pip-accel (for details refer to ec426ea).
I'll see if I can improve on this as well.
There are unit tests for the S3 backend, or rather the test suite runs twice for each supported version of Python: Once with the S3 cache backend disabled and once with the S3 cache backend enabled. This uses FakeS3 so I don't need to create and pay for an actual Amazon S3 bucket. |
I believe this is now fixed as well. As far as I can tell FakeS3 doesn't support simulating read only bucket access so I had to figure out how to create a read only IAM policy in Amazon S3 in order to test this manually. For previous manual testing I had used the following IAM policy: {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
} For this testing I switched to the following read only policy: {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:Get*", "s3:List*"],
"Resource": "*"
}
]
} In my tests the latest version correctly falls back to read only Amazon S3 access when a Can you confirm whether these changes resolve the caveats you mentioned? |
I believe the issue you reported is fixed and the caveats you mentioned are also resolved, so I'm going to go ahead and close this issue now - I'm trying to keep an overview of active/relevant issues on GitHub and the long list isn't helping :-). If you believe there are still issues with the current implementation, feel free to reopen this issue or report a new one. Thanks for suggesting the feature! |
Yes, I'm all set with this now. Thanks for all your work on this really great project. |
S3 has the ability to set ACLs for anonymous access to buckets. This is wired into boto's s3.connection.S3Connection method via the anon parameter.
Modify the S3 cache backend code so that if the user does not have credentials, it will connect as an anonymous user rather than erroring with "No handler was ready to authenticate... Check your credentials" and disabling the S3CacheBackend.
The text was updated successfully, but these errors were encountered: