Check the message after sending a PasswordMessage#5006
Check the message after sending a PasswordMessage#5006roji merged 2 commits intonpgsql:mainfrom yoshihikoueno:feature/check_authentication_ok
Conversation
…thenticationOk, otherwise follow the authentication request sent by the server
roji
left a comment
There was a problem hiding this comment.
Am not necessarily against merging this, but can you provide a bit more context on what this means, and why it authentication would need to take place twice, once in cleartext and once in MD5?
Also, note that this is explicitly against the PostgreSQL protocol docs, which state the folliowing:
For all authentication methods except GSSAPI, SSPI and SASL, there is at most one request and one response.
So PgPool-II seems to be violating the PostgreSQL protocol on this point.
|
@roji This PR makes it possible for Npgsql to react to multiple authentication requests just the same as psql and pgAdmin. As far as I understand, PgPool-II requires this two-step authentication because PgPool-II, which doesn't necessarily have information of the user that a client is trying to connect as, needs to authenticate PgPool-II itself to the backend PostgreSQL servers and authenticate the client on behalf of the actual PostgreSQL servers behind the PgPool-II.
I'm not sure about the interpretation of the cited text but the implementation of the official PostgreSQL client, libpq, does allow multiple authentication requests to occur. (ref: After sending authentication information to the server, it checks if the returned message is |
|
Thanks for the additional information @yoshihikoueno. I think it's fine for us to do this. |
(cherry picked from commit fbc7538)
|
Backported to 7.0.4 via ca43399 |
This PR fixes an issue that Npgsql fails to connect to a PostgreSQL cluster via PgPool-II as both the client and the server fall into waiting status.
Issue description
Npgsql currently assumes the message sent from the server after sending
PasswordMessageto beAuthenticationOk.However, this assumption doesn't always stand as the server may send some other messages other than
AuthenticationOksuch as another authentication request.That occurs when Npgsql 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:
StartupMessageAuthenticationCleartextPasswordPasswordMessageAuthenticationMD5PasswordPasswordMessageAuthenticationOkReadyForQueryWith the current implementation of Npgsql, the
AuthenticationMD5Passwordsent by PgPool-II is erroneously considered to beAuthenticationOkby Npgsql. At this point, Npgsql waits forReadyForQueryand PgPool-II waits forPasswordMessage, which causes a timeout error.Solution description
Clients such as psql and pgAdmin can connect to PgPool-II just fine with the procedure above, so making Npgsql check the message sent from the server after
PasswordMessageseems to be a solution.Thank you for checking out this PR. Please let me know if there's anything that is missing or needs improvements with this PR.