Prisma: Issue when connecting to DB with special characters in the password

Created on 14 Apr 2020  路  3Comments  路  Source: prisma/prisma


Hi all - I'm really enjoying this project so far, just wanted to bring a small bug to your attention!

Bug description

Seeing an issue when trying to connect to a PSQL db when using a password that has certain special characters.
Example:

datasource db {
  provider = "postgresql"
  url      = "postgres://postgres:%Q&UaU5e89vK^drgppl#[email protected]:5432/some_db"
}

doesn't work but:

datasource db {
  provider = "postgresql"
  url      = "postgres://postgres:[email protected]:5432/some_db"
}

does.

Note: I can connect with pgAdmin with the first.

How to reproduce

  1. Create a db with this password: %Q&UaU5e89vK^drgppl#q
  2. Run npx prisma migrate up --experimental
  3. You'll receive this error:
Error: Can't parse migration engine response:
undefined

Expected behavior

Can pass any valid password for a PSQL db as a schema db url.

Prisma information


See above

Environment & setup

  • OS: Mac OS
  • Database: PostgreSQL
  • Prisma version: 2.0.0-beta.2
  • Node.js version: v13.3.0
bu2-confirmed kinbug statuneeds-action tecengines connection-string

Most helpful comment

Specs issue was resolved with a decision to stay standards compliant. But we want to find a way to surface this to users that might not know and give them a helpful error message that leads them to success (by url-encoding their credentials for example).

All 3 comments

Thanks for reporting this! I read up on this and tested the current implementation. Currently the database URL needs to be a spec-compliant URL, meaning the password should be percent-encoded. This is consistent with libpq. This should be at least documented better though, I opened an issue for this: https://github.com/prisma/specs/issues/464

If you replace the password with the url-encoded version (%25Q%26UaU5e89vK%5Edrgppl%23q in your example) it should work.

At this time I think this should be considered a product issue (do we want to diverge from other libraries and have our own definition of an URL string? If yes, what should it be?). See the specs issue linked in the previous comment for details.

Specs issue was resolved with a decision to stay standards compliant. But we want to find a way to surface this to users that might not know and give them a helpful error message that leads them to success (by url-encoding their credentials for example).

Was this page helpful?
0 / 5 - 0 ratings