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

[Bug]: ConnectionFactory::getConnection parameters messed up by switch to PrimaryReadReplicaConnection #45097

Open
6 of 8 tasks
kainhofer opened this issue Apr 29, 2024 · 2 comments
Labels
1. to develop Accepted and waiting to be taken care of 29-feedback bug

Comments

@kainhofer
Copy link

⚠️ This issue respects the following points: ⚠️

Bug description

In the commit 79c4986, the Nextcloud server code switched from using \Doctrine\DBAL\Connection for the DB connections to Doctrine\DBAL\Connections\PrimaryReadReplicaConnection.

Apparently PrimaryReadReplicaConnection uses a different array structure for its arguments (connection params are stored in the ['primary'] sub-array instead of first-level array elements). Unfortunately, the code in ConnectionFactory::getConnection (

$additionalConnectionParams = array_merge($this->createConnectionParams(), $additionalConnectionParams);
) merges in the connection parameters as first-level arguments (as was required for the old Connection class) rather than into the ['primary'] sub-array, which is now needed for the PrimaryReadReplicaConnection.

So, while the old code needed

Array(
	'host' => "localhost",
	'password' => "myPassword",
	'user' => "DBUsername",
	'dbname' => "DBUserPassword"
)

to connect to a database other than the nextcloud database, the new Primary ReadReplicaConnection now needs them in the primary sub-array:

Array(
	'primary' => Array(
		'host' => "localhost",
		'password' => "myPassword",
		'user' => "DBUsername",
		'dbname' => "DBUserPassword"
	)
)

For a difference of the params, I found this nice page:
https://blog.adamcameron.me/2023/01/php-primaryreadreplicaconnection.html

I suppose the correct fix would be to properly fix the ConnectionFactory to override the primary connection data instead of merging the params at top-level, where they are never used. There actually appear some more places in the code, where connection settings appear to be merged, which probably also need fixing, so I think I'm unable to provide a proper patch to fix this issue for real.

See also my remarks and my debugging efforts in the user_sql repo: nextcloud/user_sql#193

Steps to reproduce

  1. Use the user_sql app with a database different from the nextcloud database. That plugin uses ConnectionFactory::getConnection to connect to an external user database.
  2. Try to log in.
  3. There is an error that the table cannot be found in the nextcloud database. Apparently, the array of database access parameters passed to getConnection is no longer applied.

Expected behavior

The connection should be done to the database specified in the $additionalConnectionParams argument to getConnection.

Installation method

Community Web installer on a VPS or web space

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

Apache (supported)

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 22 to 23)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

@kainhofer kainhofer added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Apr 29, 2024
@kesselb
Copy link
Contributor

kesselb commented Apr 29, 2024

Thanks for your report 👍

cc @juliushaertl @ChristophWurst

@joshtrichards
Copy link
Member

Related: #45257 (impacting db conversions).

@joshtrichards joshtrichards added 1. to develop Accepted and waiting to be taken care of and removed 0. Needs triage Pending check for reproducibility or if it fits our roadmap labels May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of 29-feedback bug
Projects
None yet
Development

No branches or pull requests

4 participants