Description

JDBC connection strings now omit user and password parameters. Credentials are provided exclusively via separate Username and Password connection properties exposed as environment variables.

Breaking Change: Applications parsing JDBC connection strings to extract credentials will break. Use the individual connection properties instead:

// Before: jdbc:postgresql://localhost:5432/db?user=postgres&password=secret
// After:  jdbc:postgresql://localhost:5432/db
//         Username available via POSTGRES_USERNAME env var
//         Password available via POSTGRES_PASSWORD env var

Changes by Database Provider

PostgreSQL

• jdbc:postgresql://{Host}:{Port}[/{Database}]?user={Username}&password={Password} → jdbc:postgresql://{Host}:{Port}[/{Database}]

MySQL

• jdbc:mysql://{Host}:{Port}[/{Database}]?user={Username}&password={Password} → jdbc:mysql://{Host}:{Port}[/{Database}]

SQL Server

• jdbc:sqlserver://{Host}:{Port};user={Username};password={Password};trustServerCertificate=true[;databaseName={Database}] → jdbc:sqlserver://{Host}:{Port};trustServerCertificate=true[;databaseName={Database}]

Oracle

• jdbc:oracle:thin:{Username}/{Password}@//{Host}:{Port}[/{Database}] → jdbc:oracle:thin:@//{Host}:{Port}[/{Database}]

Modified Components

• Resource classes: MySqlServerResource, PostgresServerResource, SqlServerServerResource, OracleDatabaseServerResource and their database child resources
• Documentation: READMEs, connection-properties.md spec, agent documentation
• Tests: ConnectionPropertiesTests for all four database providers

Fixes #<issue_number>

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue: TBD (breaking change - JDBC format changes for all database providers)
  • No

This pull request was created as a result of the following prompt from Copilot chat.

Objective:
Remove user and password query parameters or inline options from all JDBC connection strings across all database server resources (MySQL, PostgreSQL, SQL Server, Oracle, etc.), and update the code to provide these values as explicit connection properties instead. Ensure documentation, code comments, and tests reflect this change.

Tasks:

1. Refactor JDBC Connection String Logic:

   • For each relevant resource (MySqlServerResource, PostgresServerResource, SqlServerServerResource, OracleDatabaseServerResource, etc.), update the JDBC connection string builder method to:
     • Remove user and password parameters from the generated JDBC connection string expression.
     • Ensure those credentials are available as individual properties (e.g., Username, Password) in the connection properties/dictionary.
   • Update API documentation comments for each affected method/property to show new connection string format and explain how credentials are provided.

2. Update Documentation:

   • Revise all relevant README files and documentation sources (src/Aspire.Hosting.*/*README.md, root README.md, etc.)
     • Clearly document that JDBC connection strings will no longer include user/password, and credentials must be provided as individual connection properties.
     • Update connection string format examples accordingly.
     • Add a note about backward incompatibility, if appropriate.

3. Update Dashboard and Related Tools:

   • Update connection string parsers and any part of the dashboard that expect user/password in the JDBC connection string.
   • Ensure environment variable and configuration propagation logic still exposes user/password properties as before.

4. Update and Add Tests:

   • Change or create tests in all affected providers to check the new JDBC connection string format.
   • Add test coverage to ensure user/password are not present in JDBC connection string, but are available in the properties.

5. Review API surface for breaking changes:

   • Consider surface area changes for public API and highlight any breaking changes in the PR description if necessary.

Acceptance:

• No JDBC connection string includes user or password.
• All required documentation and code comments reflect new pattern.
• Properties for user and password are exposed on the connection properties collection, and documented for consumers.
• All tests for connection string formatting and property exposure pass.
• Dashboard, environment variables, and config remain functional with new split format.
• PR description summarizes all changes and docs updated locations/reasoning.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.