-
-
Notifications
You must be signed in to change notification settings - Fork 353
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
Read credentials from shared credentials file #694
Comments
I think maybe we implemented the fog credential file prior to this aws option being available, and I hadn't thought about it much since. I would be open to also supporting the aws version, though we should think carefully about precedence in the case that both files exist. I think the fog credential seems more specific, so my inclination would be toward that taking precedence if they both exist. That being said, if they both exist it should probably at least print a warning as well. Though perhaps it would be safer/better for it to simply raise an error if both exist and ask the user to sort it out. That is a bit more jarring, but I suspect might save some headaches in the longer term. What do you think? |
Hey, |
No worries, definitely no hurry from my perspective (and I'm pretty slow on things lately too, as I'm on parental leave). I definitely agree that we should avoid it suddenly changing behavior from what already worked. Though if it "automatically" works, maybe that is always going to have cases where that is true. Another option might be that it expects an option to be passed explicitly, something like |
This issue has been marked inactive and will be closed if no further activity occurs. |
We are using your gem as it is included in Carrierwave. In AWS SDK, if you don't specify credentials it will try and load them from ~/.aws/credentials. I see you have implemented your own version of that in ~.fog. I can't see that you're using this shared credential file. Would you consider supporting it? details can be seen at https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html (Where are configuration settings stored? section). For now, we will try and use the .fog workaround but it would be great if we could use the same logic that AWS is using so we don't have to keep the details in two places.
The text was updated successfully, but these errors were encountered: