-
-
Notifications
You must be signed in to change notification settings - Fork 993
Don't send AUTH and/or SELECT command after connecting to sentinels #346
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
Conversation
|
My bad, it was actually the intended behavior but I failed to notice that stripping the I was never really satisfied with the code I wrote for the configuration of the redis-sentinel backend but it was the only way to provide an easy configuration for users without pushing any breaking change, now I'm definitely convinced that this needs to be reworked for v2.0 (BCs allowed). |
|
Just updated my project and got this error.. 😭 |
|
@AaronJan For the time being this works for me in composer.json: |
|
@AaronJan this fix will be available starting with v1.1.1 but it's still unreleased (I plan to ship it tomorrow), if you need it ASAP you can tweak your |
|
Thank you guys! I'll try that. 😄 |
|
@AaronJan JFYI Predis v1.1.1 is now available. |
|
@nrk 👍 Copy that! |
Password-based authentication for sentinels has been added in Redis 5. Predis was actively ignoring any "password" parameter for sentinels when creating connections to them to avoid issues when this parameter is set in the default "parameters" array passed via client options, as they are applied to **every** connection created by Predis (see #346). We need to find a better way to specify a common password for sentinels to be handled in a different way than the ones for Redis nodes. For now each sentinel node protected by password must have an explicit password set in its parameters list even if this password, by design, is the same for all sentinels. Since we cannot use default "parameters" as explained above but we still need to pass a common value for all sentinels an idea could be using a dedicated client option like we did with "service", but we will see later. In this commit we also explicitly reset any "username" parameter as it would trigger an `AUTH $username $password` but sentinels do not support ACL authentication. Fixes #594.
Connecting to sentinels is broken with v1.1. Bad commit: 5a0dfc3#diff-e55f11b907debe0b57a114d0c38dc563R244.
AUTH and/or SELECT commands are sent to sentinels when password or database is specified. Sentinels don't understand these commands and thus master discovery fails and a Predis\ClientException with message "No sentinel server available for autodiscovery." is thrown.
We need to explicitly specify a null password and database.