Password authentication fails and server fails to connect to database

[pmmlo]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest version of Parse Server.

Issue Description

From pre-release 5.0.0-alpha.16 to 5.0.0-alpha.17, I get the following critical error: error: password authentication failed for user "X", using PostgreSQL 14.x with enforced TLS.

Steps to reproduce

1. Setup a base Express Server setup.
2. Run Parse, GraphQL, and LiveQuery servers.
3. Confirmation all servers are started without issue.
4. Error occurs following the start of the servers.

Actual Outcome

error: password authentication failed for user "X" and server fails to connect to database.

Expected Outcome

No error. Successful connection to database.

Environment

PostgreSQL 14.x with TLS enforced.

Server

• Parse Server version: 5.0.0-alpha.17
• Operating system: Dockers on unix
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local

Database

• System (MongoDB or Postgres): Postgres
• Database version: 14.x
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): local

Client

• SDK (iOS, Android, JavaScript, PHP, Unity, etc): JS
• SDK version: Default in version.

Logs

error: password authentication failed for user "X" and server fails to connect to database.

[parse-github-assistant]

Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

[ThornWu]

Did the client correctly being initialized before using it?

parse-server/src/ParseServer.js

Line 78 in 826aa79

const allControllers = controllers.getControllers(options);

parse-server/src/Controllers/index.js

Line 43 in 826aa79

const databaseController = getDatabaseController(options);

parse-server/src/Controllers/index.js

Line 155 in 826aa79

databaseAdapter = getDatabaseAdapter(databaseURI, collectionPrefix, databaseOptions);

parse-server/src/Controllers/index.js

Lines 230 to 234 in 826aa79

	return new PostgresStorageAdapter({
	uri: databaseURI,
	collectionPrefix,
	databaseOptions,
	});

parse-server/src/Adapters/Storage/Postgres/PostgresStorageAdapter.js

Lines 846 to 847 in 826aa79

	const { client, pgp } = createClient(uri, databaseOptions);
	this._client = client;

parse-server/src/Adapters/Storage/Postgres/PostgresStorageAdapter.js

Lines 1263 to 1269 in 826aa79

	async getAllClasses() {
	return this._client.task('get-all-classes', async t => {
	return await t.map('SELECT * FROM "_SCHEMA"', null, row =>
	toParseSchema({ className: row.className, ...row.schema })
	);
	});
	}

[mtrezza]

From pre-release 5.0.0-alpha.16 to 5.0.0-alpha.17, I get the following critical error

Just to confirm, you do not get that error with 5.0.0-alpha.15?

[pmmlo]

Just to confirm, you do not get that error with 5.0.0-alpha.15?

I actually checked 5.0.0-alpha.16. Works without issue. I also tried 5.0.0-alpha.18 with the change manually reverted and no issue.

[mtrezza]

@pmmlo would you please try to write a failing test for this issue? this is currently blocking the Parse Server 5 release, so it would be great if we could solve this within the next few days. being able to reproduce this would be an important first step. if we cannot reproduce this issue, we can't fix it and we'd assume that it's a custom code issue in your environment, so we'd make a release with this uncertainty.

If you cannot reproduce this with a test, I'd just set a breakpoint for the auth error and then go back step-by-step in the caller chain to find the issue. You could also compare the behavior this way for both, the working code without the change in #7678 and the failing code with the change.

Referencing your comment as it contains some more details.

[pmmlo]

@pmmlo would you please try to write a failing test for this issue? this is currently blocking the Parse Server 5 release, so it would be great if we could solve this within the next few days. being able to reproduce this would be an important first step. if we cannot reproduce this issue, we can't fix it and we'd assume that it's a custom code issue in your environment, so we'd make a release with this uncertainty.

If you cannot reproduce this with a test, I'd just set a breakpoint for the auth error and then go back step-by-step in the caller chain to find the issue. You could also compare the behavior this way for both, the working code without the change in #7678 and the failing code with the change.

Referencing your comment as it contains some more details.

In that case, I suggest just proceeding with the community plan. I'm just reporting bugs and issues that I think could potentially become bigger problems. At least now, we know a similar db auth error in the future could stem from this seemingly unrelated line.

I think this most certainly could be an implementation case.

For example, in the test environment, I enforced strict TLS to authenticate postgres. In a production environment, I think that should be done for most cases but understand not everyone can/does. Could also be other configurations in postgres, firewall ports, private network...

If I'm the only one running into this issue, I say just send it. Worst case is it becomes a widespread issue and we just revert that line in the future (low chance of merge conflict).

@mtrezza Cheers for looking into the issue with me.

[pmmlo]

I never tested alpha 15 but no errors on alpha 16.

…

On Jan 22, 2022, 7:58 AM -0800, Manuel ***@***.***>, wrote: @pmmlo would you please try to write a failing test for this issue? this is currently blocking the Parse Server 5 release, so it would be great if we could solve this within the next few days. being able to reproduce this would be an important first step. if we cannot reproduce this issue, we can't fix it and we'd assume that it's a custom code issue in your environment, so we'd make a release with this uncertainty. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mtrezza]

@pmmlo just before we close this issue, could you help me trying to reproduce this?

Does this issue occur also without GraphQL and LiveQuery servers and only a fresh, plain install of Parse Server connected to PostgreSQL 14.x with TLS enforced? And if you turn off TLS does the issue go away?

[pmmlo]

It’s tough to replicate my environment because you would have to setup a production distributed architecture on k8s.  It lets me see where Parse is in a realistic environment.  I wrote up a single command script to setup new clusters but can’t share it. The basics: HA postgres with gis 14.1 deployed in a vps with firewall/port forwards, parse-server replicas. I don’t run Parse in a real production application.  I just contribute as I can and check-in from time to time. It sounds like the community is seeing a caching/idempotency issue that I haven’t encountered, which requires the line.  It seems like I’m the only one running into this so I say do the community consensus: push the current commits as-is.

…

On Jan 22, 2022, 4:14 PM -0800, Manuel ***@***.***>, wrote: Reopened #7778. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mtrezza]

I see, then let's assume for now that it's an env specific issue, close it and release Parse Server 5. We can try to keep this in mind in case related issues pop up in the next couple of weeks after v5 release. In case you find the time to try to reduce this issue down to a simple deployment of Parse Server that one can reproduce locally, we can pick this up again, but in any case I expect we'd get feedback if this is really a server bug.