Skip to content
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

Database switching when using authentication proxy results in authentication method error #1534

Open
adamkirkton opened this issue Dec 14, 2024 · 3 comments

Comments

@adamkirkton
Copy link

Software versions
MySqlConnector version: 2.3.7
Server type: MySQL 8.0.35 (using Google Cloud SQL service)
.NET version: 8.0

Describe the bug
The connection to my MySQL instance goes through Google's cloud-sql-proxy which is a little app that allows you to authenticate to the database using IAM authentication as well as manage SSL for you. All I provide via the connection string to MySqlConnector is a username and when I connect to the proxy and it then actually connects to MySQL, it does so with an OAuth token that it automatically rotates.

I am not specifying a database in the connection string because I have a multi-tenant setup with multiple databases and so want to switch the database at runtime. The problem becomes when I call ChangeDatabase or ChangeDatabaseAsync this will cause the else statement in TryResetConnectionAsync to be executed which ends up with an attempt to re-authenticate the user which ultimately results in an exception being thrown in SwitchAuthenticationAsync.

Exception
MySqlConnector.MySqlException (0x80004005): Authentication method 'mysql_clear_password' requires a secure connection. at MySqlConnector.Core.ServerSession.SwitchAuthenticationAsync(ConnectionSettings cs, String password, PayloadData payload, IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnector/Core/ServerSession.cs:line 670 at MySqlConnector.Core.ServerSession.TryResetConnectionAsync(ConnectionSettings cs, MySqlConnection connection, IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnector/Core/ServerSession.cs:line 620 at MySqlConnector.Core.ConnectionPool.GetSessionAsync(MySqlConnection connection, Int64 startingTimestamp, Int32 timeoutMilliseconds, Activity activity, IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnector/Core/ConnectionPool.cs:line 72

Expected behavior
I was wondering if the re-authentication upon switching databases is strictly necessary or if it's rather done as a precaution to know when you are trying to access something you can't and letting you know immediately. If it is the latter case, and there was a configuration option somewhere to disable that functionality, I'd be all set.

Additional context
The primary reason I am trying to do this is get to a unified connection pool for connections to my server so I can effectively manage a pool. Otherwise, I end up with a pool per client database.

Thanks for the consideration!

@bgrainger
Copy link
Member

MySqlConnector.MySqlException (0x80004005): Authentication method 'mysql_clear_password' requires a secure connection.

The Google Cloud SQL Auth Proxy is listening on a local port, right? (e.g., 127.0.0.1:1234) If so, this is probably something MySqlConnector should detect and allow, because we don't need to worry about the connection being intercepted in this scenario.

@bgrainger
Copy link
Member

I was wondering if the re-authentication upon switching databases is strictly necessary

No, it's not. It's done because "Reset Connection" doesn't reset the database back to the one that was specified in the original connection string (or to "no database"), but reauthenticating does easily allow the database from the connection string to be selected (so that the connection is in a well-known state, whether or not it was filled from the pool or newly opened).

@adamkirkton
Copy link
Author

The Google Cloud SQL Auth Proxy is listening on a local port, right? (e.g., 127.0.0.1:1234) If so, this is probably something MySqlConnector should detect and allow, because we don't need to worry about the connection being intercepted in this scenario.

That's correct about listening on the loopback address on a local port.

No, it's not. It's done because "Reset Connection" doesn't reset the database back to the one that was specified in the original connection string (or to "no database"), but reauthenticating does easily allow the database from the connection string to be selected (so that the connection is in a well-known state, whether or not it was filled from the pool or newly opened).

Ah, ok, that makes sense then. Thanks for the explanation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants