Skip to content

URL encode username and password values for DB connections#7486

Draft
wadesdev wants to merge 1 commit intomainfrom
wades/ENG-2808
Draft

URL encode username and password values for DB connections#7486
wadesdev wants to merge 1 commit intomainfrom
wades/ENG-2808

Conversation

@wadesdev
Copy link
Contributor

@wadesdev wadesdev commented Feb 25, 2026

Ticket ENG-2808

Description Of Changes

This should resolve an issue wherein passwords with special characters are properly URL encoded, precluding SQLAlchemy parsing issues.

Code Changes

  • Updates MySQL, Postgres, and Redshift connectors to URL encode username and password fields

Steps to Confirm

  1. Bring a MySQL database to the table
  2. Create a user with @ in the password
  3. Create a MySQL integration
  4. [Confirm Step 1] Test integration should pass
  5. [Confirm Step 2] Monitor scan should create staged resources

Pre-Merge Checklist

  • Issue requirements met
  • All CI pipelines succeeded
  • CHANGELOG.md updated
    • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
    • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
    • Updates unreleased work already in Changelog, no new entry necessary
  • UX feedback:
    • All UX related changes have been reviewed by a designer
    • No UX review needed
  • Followup issues:
    • Followup issues created
    • No followup issues
  • Database migrations:
    • Ensure that your downrev is up to date with the latest revision on main
    • Ensure that your downgrade() migration is correct and works
      • If a downgrade migration is not possible for this change, please call this out in the PR description!
    • No migrations
  • Documentation:
    • Documentation complete, PR opened in fidesdocs
    • Documentation issue created in fidesdocs
    • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
    • No documentation updates required

@vercel
Copy link
Contributor

vercel bot commented Feb 25, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
fides-plus-nightly Ignored Ignored Feb 25, 2026 7:20pm
fides-privacy-center Ignored Ignored Feb 25, 2026 7:20pm

Request Review

Copy link
Contributor

@vcruces vcruces left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! I added a comment recommending a defensive check, just to be safe

database = f"/{config.database}" if config.database else ""
url = f"redshift+psycopg2://{config.user}:{config.password}@{local_host}{port}{database}"
user = quote(str(config.user), safe="")
password = quote(str(config.password), safe="")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding a check to ensure the credential exists before applying str?

If config.password is None, str(None) converts this to the literal string "None", resulting in URLs like: redshift+psycopg2://user:None@...

This differs from the MySQL/Postgres implementation, which conditionally includes credentials only when they exist

config = self.secrets_schema(**self.configuration.secrets or {})

url_encoded_password = quote_plus(config.password)
user = quote(str(config.user), safe="")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed this changed from quote_plus to quote. I don’t see an issue with using quote here, if anything, it may even be preferable, but I’m wondering whether the original use of quote_plus was intentional 🤔

Not raising this as a change request, just something to keep in mind in case we see any related behavior changes down the line

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

Successfully merging this pull request may close these issues.

2 participants