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

no way to set rejectUnauthorized from pg-connection-string #2281

Open
hjr3 opened this issue Jul 16, 2020 · 8 comments
Open

no way to set rejectUnauthorized from pg-connection-string #2281

hjr3 opened this issue Jul 16, 2020 · 8 comments

Comments

@hjr3
Copy link
Contributor

hjr3 commented Jul 16, 2020

Now that rejectUnauthorized is being defaulted to true, there is no way to modify that from the connection string. Some libraries (example are setting opposite defaults to try and ease the migration.

@hjr3
Copy link
Contributor Author

hjr3 commented Jul 16, 2020

My recommendation:

In general, we should adhere to the libpq connection URI documentation. Specifically, we should support the Parameter Key Words.

  • introduce sslmode. For non-native mode, I do not think we can easily support allow or prefer. I also think verify-ca will not work as expected as rejectUnauthorized seems to check the host. We can document the mapping for non-native mode like this:
sslmode Will connection via SSL/TLS? rejectUnauthorized
disable no n/a
allow no n/a
prefer no n/a
require yes false
verify-ca yes false
verify-full yes true

I do not feel great about verify-ca not setting rejectUnauthorized = true. brianc/node-postgres-docs#79 shows that rejectUnauthorized often requires the host to be specified. This is more strict than the true meaning of verify-ca. That being said, I wonder if we should make it rejectUnauthorized = true even though the postgres documentation states that verify-ca will not check the host.

  • deprecate ssl. If both ssl and sslmode are specified, sslmode will win
  • if ssl is set, also set rejectUnauthorized: true. This maintains the node default but makes it more obvious as to what is going on

@hjr3
Copy link
Contributor Author

hjr3 commented Jul 16, 2020

If #2263 lands, then maybe verify-ca will just work ™️

@lroal
Copy link

lroal commented Nov 5, 2020

I have the same problem. Any solution on this ?

@radcapitalist
Copy link

radcapitalist commented Feb 12, 2021

+1 for supporting sslmode keywords. I expected:
ssl: { require: false }
to be equivalent to the "allow" sslmode keyword, so that my connection would use SSL if the server allowed or required it but not if it didn't. I don't see a way to get the equivalent of "allow" with node-postgres.
UPDATE: I don't think require: false is a valid option in the ssl object. I saw an example here but it is not in the node-postgres doc.

@the21st
Copy link

the21st commented Sep 2, 2021

We are struggling with this as well. Ideally we want to be able to set sslmode: prefer for the ssl option.

@bdwyertech
Copy link

You can pass sslmode=no-verify in the connection string or you can set env var PGSSLMODE=no-verify

@ollytheninja
Copy link

ollytheninja commented Jan 18, 2022

Hi everyone, I have a requirement to use verify-ca - with the AWS RDS proxy service the hostname is invalid and you can only check the CA. The OS already has the relevant AWS CA installed.

I'm not clear on whether doing the above (set rejectUnauthorized: false) will actually check the CA?
Is there an equivalent to the native verify-ca option or do I need to specify the CA certificate to make it check just the CA?

👍 for having an sslmode argument but want to make sure it'll actually match psql configuration exactly

@ceefour
Copy link

ceefour commented Dec 28, 2022

@bdwyertech mentioned good-enough workaround:

You can pass sslmode=no-verify in the connection string or you can set env var PGSSLMODE=no-verify

It is undocumented by libpq but mentioned by @pmalouin here: #2709 (comment)

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

No branches or pull requests

7 participants