server: handle clients without authplugin support

[dveeden]

What problem does this PR solve?

Issue Number: close #27855

Problem Summary:

Old (MySQL 5.1 and before) clients that don't send authentication plugin info in the login packet were having issues authenticating and/or got an incorrect error message

What is changed and how it works?

1. The code now checks for mysql.ClientPluginAuth in resp.Capability.
2. Instead of returning an error it now logs a warning if it encounters an unknown authentication plugin

Check List

Tests

• Unit test
• Manual test (add detailed scripts or steps below)

Documentation

• Affects user behaviors
• Changes MySQL compatibility

Release note

Fixed a bug where MySQL 5.1 and older clients had issues authenticating

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• morgo
• sylzd

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[dveeden]

/cc @morgo @tiancaiamao @time-and-fate

[morgo]

LGTM

[bb7133]

LGTM for the rest of the code, but I'm not an expert of authfication, just want to check if this is expected:

mysql/5.1.30/bin/mysql -u u1 -h 127.0.0.1 -P 4000 -pabc -e QUIT
# OK

mysql/5.1.30/bin/mysql -u u2 -h 127.0.0.1 -P 4000 -pabc -e QUIT
ERROR 1045 (28000): Access denied for user 'u2'@'127.0.0.1' (using password: YES)

mysql/5.1.30/bin/mysql -u u3 -h 127.0.0.1 -P 4000 -pabc -e QUIT
ERROR 1045 (28000): Access denied for user 'u2'@'127.0.0.1' (using password: YES)

(the case from your comment: #27855 (comment))

[dveeden]

LGTM for the rest of the code, but I'm not an expert of authfication, just want to check if this is expected:

mysql/5.1.30/bin/mysql -u u1 -h 127.0.0.1 -P 4000 -pabc -e QUIT
# OK

User exists, password is correct and authentication method is supported by client and server => OK

mysql/5.1.30/bin/mysql -u u2 -h 127.0.0.1 -P 4000 -pabc -e QUIT
ERROR 1045 (28000): Access denied for user 'u2'@'127.0.0.1' (using password: YES)

Authentication method (caching_sha2_password) is not supported by the client, failing as expected.

mysql/5.1.30/bin/mysql -u u3 -h 127.0.0.1 -P 4000 -pabc -e QUIT
ERROR 1045 (28000): Access denied for user 'u2'@'127.0.0.1' (using password: YES)

Account doesn't exist, failing as expected.

Testing the same against MySQL 8.0.26:

[dvaneeden@dve-carbon tidb]$ ~/opt/mysql/5.1.73/bin/mysql -u u1 -h 127.0.0.1 -P 8026 -pabc -e QUIT
[dvaneeden@dve-carbon tidb]$ ~/opt/mysql/5.1.73/bin/mysql -u u2 -h 127.0.0.1 -P 8026 -pabc -e QUIT
ERROR 1251 (08004): Client does not support authentication protocol requested by server; consider upgrading MySQL client
[dvaneeden@dve-carbon tidb]$ ~/opt/mysql/5.1.73/bin/mysql -u u3 -h 127.0.0.1 -P 8026 -pabc -e QUIT
ERROR 1045 (28000): Access denied for user 'u3'@'localhost' (using password: YES)

So there is a difference between the MySQL behavior and this PR: The error for the second case is different.

[sylzd]

I've met the same issue by client github.com/ziutek/mymysql/mysql. Plz cherry-pick it on v5.2.X.

[sylzd]

LGTM. Old client should keep the compatibility because many old codes like availability monitors runs online.

[sylzd]

@morgo plz help to merge~ 🤣 Then we can skip the v5.2.1 to a new version before putting the cluster into production.

[morgo]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 013102d

[ti-srebot]

cherry pick to release-5.2 in PR #28734