-
Notifications
You must be signed in to change notification settings - Fork 163
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
Support dynamic passwords #1109
Comments
After further exploration, I was able to inject a dynamic password somewhat OK-ish:
Not great UX, but okay. Would still be cool to have a method on |
If that works well, perhaps you could open a PR to add that generalized version of |
Unfortunately, at $work we paused migration to both skunk and RDS IAM (for reasons unrelated to skunk itself), so while I know I got it to compile once, I'm currently not in a good position to properly test it. If/When we get back to it and I'm sure it works reliably, I'm happy to contribute as you suggested :) In the meantime, anyone feel free to pick this up if you like to, it shouldn't be too hard to implement (just a bit of bincompat care and real testing is bit ugly). |
Use Case
At $work, we're looking to switch from doobie to skunk. One obstacle on the migration comes from the likely requirement to use AWS RDS IAM. It integrates Postgres authentication with AWS IAM by signing short-lived (15 min) tokens that can be used as password when connecting to RDS Postgres. The problem with skunk is that it expects the password to be static, it's just
String
in all relevant signatures.Feature request
Unless I'm overlooking some smart way to deal with a connection pool and a dynamic password in the existing setup, it would be cool if skunk added support. From what I've seen at first glance, taking a
F[String]
(or maybe more general aF[SomeConnectionParamsIncludingPassword]
that is evaluated when the connection is established, would help to support it. The existing (public) method signatures could just lift the password usingpure
, for RDS IAM, the effect would ask the AWS SDK for a fresh/TTL-aware-cached token.The text was updated successfully, but these errors were encountered: