How is it possible to specify the access key and secret access key? about s3rver HOT 5 CLOSED

@smeijer If you aren't discarding s3rver entirely, maybe try updating the source code yourself to see if you can add this functionality based on AWS docs? If it works we'd love to have a PR implementing this.

from s3rver.

@christianbaun Sorry this issue hasn't seen a response in so long.

Were you hoping to specify a set of permitted credentials? There is currently no feature to enforce access security in this mock S3 server implementation. If you're interested in seeing such a feature, please provide more details about your use case. I'd be happy to consider implementing a feature if there is a strong case for it. I'd also review and merge a PR if you'd like to implement it!

from s3rver.

Wouldn't that be crucial to test access rights? And to test if the sign logic has been implemented correctly?

Without this, it would be possible that we can communicate with the test server, but that we will receive authentication errors as soon as we hook up to Amazon S3 in production.

from s3rver.

@smeijer You make a fair point about testing if auth logic has been implemented correctly – I can imagine writing an integration test for how an app responds to authentication errors, which is currently impossible because s3rver doesn't give authentication errors.

However even if you could specify credentials for S3rver, that doesn't prevent possible authentication issues in production afterwards – your AWS environment's credentials can vary from your test parameters. So that risk cannot be reliably mitigated this way.

If you're familiar with S3's expected behaviour for different access/auth scenarios, please post a new issue describing what you think the expected behaviour should be, referencing the relevant docs that specify expected behaviour, and write failing tests if possible. This would make it much more likely someone will implement your desired feature.

from s3rver.

your AWS environment's credentials can vary from your test parameters. So that risk cannot be reliably mitigated this way.

Not just can, they should. Never use production credentials in test / dev environments.

Still, authentication logic should be tested. There is a difference between failing a deploy because you supplied the incorrect credentials, or failing because your (signature) hashing algorithm has a bug.

Again, I like this project. But the lack of this functionality is a big loss.

from s3rver.