Remove assumption that the auth response is AuthenticateOk #1188
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yoshihikoueno
force-pushed
the
feature/support_multi_auth
branch
from
388e66a to
ca66dd0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to solve an issue where lib/pq fails to connect to a PostgreSQL cluster via PgPool-II.
Issue description
lib/pq currently assumes the message sent from the server after sending PasswordMessage to be AuthenticationOk.
However, this assumption doesn't always stand as the server may send some other messages other than AuthenticationOk such as another authentication request.
That occurs when lib/pq is trying to connect to a PgPool-II server, where the following procedure is required as PgPool-II wants to have the password in both Cleartext and MD5 formats:
[Client -> Server] StartupMessage
[Server -> Client] AuthenticationCleartextPassword
[Client -> Server] PasswordMessage
[Server -> Client] AuthenticationMD5Password
[Client -> Server] PasswordMessage
[Server -> Client] AuthenticationOk
[Server -> Client] ReadyForQuery
Solution description
Current implementation of auth function of lib/pq will fail if the message after sending credentials is not AuthenticationOk, but we can just return before checking it and let another loop of auth check it instead.
The official client libpq (and of course softwares that use it such as psql and pgAdmin) does support handling multiple authentication requests, thus it can connect to PgPool-II just fine with the procedure above. So making lib/pq check the message sent from the server after PasswordMessage will solve the described issue and align its behavior with the official client.
Thank you for checking out this PR. Please let me know if there's anything that is missing or needs improvements with this PR.