Support dynamic passwords
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 a F[SomeConnectionParamsIncludingPassword] that is evaluated when the connection is established, would help to support it. The existing (public) method signatures could just lift the password using pure, for RDS IAM, the effect would ask the AWS SDK for a fresh/TTL-aware-cached token.
After further exploration, I was able to inject a dynamic password somewhat OK-ish:
- Copy
Session.pooledF's implementation - Replace the
passwordparameter by an effect supplying the password - In the inner method called
session, evaluate that effect to obtain the current password
Not great UX, but okay. Would still be cool to have a method on Session that did this directly, pooledF could just delegate with a pure effect.
If that works well, perhaps you could open a PR to add that generalized version of pooledF and pooled to Session.
If that works well, perhaps you could open a PR to add that generalized version of
pooledFandpooledtoSession.
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).
Hi @ybasket, facing with something similar at $WORK. Glad to take over if the offer stil stands
@ant8e Sure, go ahead 👍
https://github.com/typelevel/skunk/issues/1109#issuecomment-2243003696 should give good indication of what's needed and while I won't get to adopt skunk at $WORK, I'd be happy to take a look at a PR or play rubber duck.