dynamic-from-file does not allow urlencoding password in connection string

[mzeiher]

Version Information

Server Version: v2.48.1-ce CLI Version (for CLI related issue):

Environment

GCP Cloud run

What is the current behaviour?

I mount the connection string to the database from a secret to the filesystem and use dynamic-from-file:// in HASURA_GRAPHQL_METADATA_DATABASE_URL.

If the connection string contains url encoded special characters hasura quits with

{code: postgres-error, error: connection error, internal: connection to server at "XXX" (XXX), port 5432 failed: FATAL:  password authentication failed for user "postgres"
connection to server at "XXXX" (X.X.X.X), port 5432 failed: FATAL:  password authentication…

If the connection string does not use urlencoding of the password it works (but will clash if password has a @ in it)

If the connection string has a plain text everything works

If writing the connection string directly in the env variable (also url encoded) everything works

What is the expected behaviour?

Hasura connects to postgres with a url encoded password in the dynamic-from-file connection string

How to reproduce the issue?

1. urlencode password in secret -> load via dynamic-from file
2. -> connection fails
3. don't url encode password in secret -> load via dtnamic-from-file
4. everyhting works

Screenshots or Screencast

Please provide any traces or logs that could help here.

detail: {
info: {
database_url: "dynamic-from-file:///etc/hasura/secrets/<secret>"
retries: 1
}
kind: "postgres_connection"
}

detail: {
message: {
host: "Unknown or invalid host"
message: "Postgres connection failed"
retry_attempt: 1
}

{code: postgres-error, error: connection error, internal: connection to server at "XXX" (XXX), port 5432 failed: FATAL:  password authentication failed for user "postgres"
connection to server at "XXX" (XXX), port 5432 failed: FATAL:  password authentication…

Any possible solutions/workarounds you're aware of?

Workaround -> write connection string into env variable (which we don't really want since the password is more exposed

Keywords

[robertjdominguez]

Thanks, @mzeiher — I'm tagging this for internal triage.

[jberryman]

@mzeiher we currently url-encode the password from the query string in the file in the dynamic-from-file mode (so in your case it was escaping twice). The inconsistency isn't ideal, but I'm not certain we can change it at this point. If you are able to store a query string with the un-urlencoded password that may be a workaround