Ex-aws Default Provider Chain Issues

I’m working on a project involving ex-aws and I’ve run into what I believe to be an inconsistency with how the library handles the AWS Default Credential Provider Chain. My understanding is that AWS encourages a using a prioritized list for where aws credentials should be found, seen here.

For the most part, ex-aws seems to follow this provider chain; however, it diverges when it comes to using the credentials file which requires both adding an additional dependency and explicitly stating that the credentials file is to be used for authentication.

It is my belief that the library should follow the provider chain without additional configuration; i.e. if it doesn’t find credentials in higher priority options, it should automatically look in the credentials file without having to be explicitly configured to do so.

I’m reaching out here, as directed by the ex-aws issues template, in the hopes that someone can shed light on this matter.

Thanks!
Vishal

2 Likes

Hey!

To be clear, you’re linking to Java documentation. I haven’t at this point seen anything from AWS that indicates that support for a credentials file is part of any formal spec.

I won’t disagree that built in support for the credentials file is common, but following the conventions of certain other client libraries is merely one of several goals. Minimalist and unopinionated dependencies are also a goal.

I can look into making the default provider chain “just work” if the dependency is included, but I am reluctant to make the dependency required.

1 Like

That may be a link to the Java documentation, but you can step through the links for all 8 official SDKs here: https://aws.amazon.com/documentation/ (bottom right). They each describe a standard credential lookup methodology that includes automatic detection and usage of a credentials file as part of the standard SDK credential lookup process. A process that is idiomatic across the SDK for each supported language.

I don’t know what a formal spec would look like here (unlikely Amazon is interested in creating one), but there does appear to be an informal standard at least. The credential lookup flow is formalized within the API documentation for each language. And they all follow the same lookup workflow (without additional configuration or dependency).

You’re of course allowed to have your fantastic library handle this detail differently. There is no formal standard. But you might confuse and irritate those coming from a language with an official SDK to Elixir.

2 Likes

To add to @CptnKirk’s point, I believe that placing the onus of selecting a credential method on the client is rather cumbersome due to running this library in multiple environments. I’d like to be able to use my credentials file when developing locally; however, for applications deployed in production, I’d like to use environment variables. Without support for the default credential flow, the burden is now placed on the client to develop a system to identify its current environment in order to select the correct credential method.

1 Like

This is definitely true.

To be clear, ExAws by default does follow the default credential flow, just without the dot file bits. It also lets you configure your own provider chains. There is never any need to know develop a system to identify the current environment.

On the whole I am loath to make the dependency mandatory, but perhaps the following solution may work for everyone:

If the :configparser_ex dependency is added, then the default provider chain will include the dot files. If the dependency is not there we will continue to use the default behaviour today.

1 Like

This works for me