Replies: 3 comments 1 reply
-
Oh, to follow up just a bit .... we removed the connection pooling, and we are using clustered redis. Without connection pooling, and using a RedisCredentialsProvider, it appears that the reconnect internal to lettuce is handling things for us, and creating a new connection before we invoke anything. Would be nice; but the use of the connection pool, we end up with connections that are configured with the old password and the auto-reconnect is NOT pretty, and we fail with the invalid username/password error message. Scratching our heads, and testing more. |
Beta Was this translation helpful? Give feedback.
-
Since introduction of the ACL commands, you can rotate passwords by adding a new password and removing the old password after the last client has received the new password. |
Beta Was this translation helpful? Give feedback.
-
Thx. Using We're still digging and running tests; still puzzling over why this didn't seem to work with a generic pool of connections, too. Here is how we are currently configuring our connection, complete with diagnostic logging that we have added:
For now, we're wiring this into our delegate, which invokes If there is anything you see in here that we are doing wrong, please let us know. There is very little I could find out there how folks are handling rotating passwords from the client perspective. |
Beta Was this translation helpful? Give feedback.
-
Been doing a lot of digging on how best to handle a rotating password on Redis. We don't really need a connection pool (just doing some simple get/set in a java app). Not ready to use spring-data-redis yet, either .... just basic plain jane lettuce/redis.
Our thinking is to catch the exception that happens when an invalid password is used, and replace the connection with a new one and retry the operation.
Is there a better way to handle a rotating password on Redis more cleanly? I see that people have done so but ... no details on how.
Beta Was this translation helpful? Give feedback.
All reactions