Fork me on GitHub

Hi @devn. You're correct — aws-api does not include a built-in provider for the assume role scenario. You can write one and add it in, if you'd like. Here's a POC


thanks kenny


@devn if you need more inspiration - here are two developed by my team( for ECS and SSO profiles):


beautiful. i wonder: is there any chance the aws-api default-credentials-provider will expand in the near future to include these kinds of things, or is the vibe like: “well, you can make your own provider, so no”


I believe it's the 2nd option, my understanding is that aws-api is just for communication with the API itself, how you authorize it is up to you


it's not an equivalent of the official AWS SDK basically, which comes with a lot of extra functionality beyond API integration (for example S3 request pre-signing is a SDK feature, not covered by the API)


if i were more ambitious id probably try to build out some of these providers and drop them in a lib because for instance, sts assume role is not a rare case


yeah, we have an internal wrapper around aws-api which does exactly that (+ a couple of other things that we needed)


what if… hear me out.. it were an external wrapper 😉

😆 1

heh, we can't disclose too much of our secret sauce 😉

Karol Wójcik18:11:52

I got the question. Why you don’t use official SDK V2 if you know that there are some limitations that you face in aws-api? Not a rant or anything like that, just curiosity.


depends on what you want to do, I think it's ok to use both if you can get best of both worlds (like presigned signature calculation or multipart parallel S3 downloads with TansferManager, but have a more data like access to other APIs)


heh, we can't disclose too much of our secret sauce 😉


@karol.wojcik that's a fair question, right now we use the official SDK only for s3 url presigning, but we keep extending our usage of S3 apis, and they way they're modeled in aws-api is way easier to handle than the interop - in this case it's pretty verbose when using the Java SDK


literally just did a presigned URL thing and ultimately decided to just skip using aws-api due to credentials providers and this


yeah, if it's only about that - I wouldn't bother with aws-api, but as I mentioned - we use S3 in a lot of different ways beyond get/put/delete


yeah that’s totally fair


i would love to have been able to use it without feeling like i was forcing the issue to stay in clojure-y land


but that’s kind of how it wound up feeling

Karol Wójcik20:11:35

Got it. You have to keep aws-api for consistency and because it makes easier to reason about the code.


Yes, if we need to use a specific API, we just use it, rather than figure out how to use PutObjectRequest class

👍 1