You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Password authentication fails and server fails to connect to database #7778
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
Setup a base Express Server setup.
Run Parse, GraphQL, and LiveQuery servers.
Confirmation all servers are started without issue.
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
🚀 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.
changed the title [-]v5.0.0-alpha.17: error: password authentication failed for user "X" and server fails to connect to database.[/-][+]Password authentication fails for user "X" and server fails to connect to database[/+]on Jan 17, 2022
changed the title [-]Password authentication fails for user "X" and server fails to connect to database[/-][+]Password authentication fails and server fails to connect to database[/+]on Jan 17, 2022
@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 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.
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: ***@***.***>
@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?
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: ***@***.***>
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.
Activity
parse-github-assistant commentedon Jan 17, 2022
Thanks for opening this issue!
ThornWu commentedon Jan 17, 2022
Did the client correctly being initialized before using it?
parse-server/src/ParseServer.js
Line 78 in 826aa79
parse-server/src/Controllers/index.js
Line 43 in 826aa79
parse-server/src/Controllers/index.js
Line 155 in 826aa79
parse-server/src/Controllers/index.js
Lines 230 to 234 in 826aa79
parse-server/src/Adapters/Storage/Postgres/PostgresStorageAdapter.js
Lines 846 to 847 in 826aa79
parse-server/src/Adapters/Storage/Postgres/PostgresStorageAdapter.js
Lines 1263 to 1269 in 826aa79
[-]v5.0.0-alpha.17: error: password authentication failed for user "X" and server fails to connect to database.[/-][+]Password authentication fails for user "X" and server fails to connect to database[/+][-]Password authentication fails for user "X" and server fails to connect to database[/-][+]Password authentication fails and server fails to connect to database[/+]mtrezza commentedon Jan 17, 2022
Just to confirm, you do not get that error with 5.0.0-alpha.15?
pmmlo commentedon Jan 17, 2022
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 commentedon Jan 22, 2022
@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 commentedon Jan 22, 2022
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 commentedon Jan 22, 2022
mtrezza commentedon Jan 23, 2022
@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 commentedon Jan 23, 2022
mtrezza commentedon Jan 23, 2022
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.