Test Connection in UI sends masked password placeholder instead of stored password value

[tholar1000]

Apache Airflow version

Other Airflow 3 version (please specify below)

If "Other Airflow 3 version" selected, which one?

3.1.4

What happened?

When testing a saved connection via the UI "Test" button, the API endpoint /api/v2/connections/test receives *** as the literal password value instead of the actual stored password. This causes every saved connection test to fail with "Authentication failed" even though the connection works correctly when used in DAGs.

Evidence from debugging inside the API server pod:

1. Connection.get_connection_from_secrets('testsftp').password returns the correct password (16 chars)
2. Direct Paramiko connection using the stored password succeeds: "Authentication (password) successful!"
3. The UI Test button sends a POST to /api/v2/connections/test with password: "***" in the request payload (visible in browser DevTools)
4. The API returns {status: false, message: "Authentication failed."} because it tests with the literal *** string

This appears related to #52301 (literal asterisks for sensitive Extra fields), but that fix only addressed Extra fields — the password form field still sends the masked placeholder when testing.

What you think should happen instead?

The Test Connection button should either:

1. Retrieve the stored password from the database for the test (when the password field still contains the masked placeholder), or
2. Allow the user to clearly re-enter the password in the form before testing

Currently, the password field appears masked and the masked value is sent as the literal password, making it impossible to test saved connections without workarounds.

How to reproduce

1. Create any connection with a password (e.g., SFTP with conn_type: sftp) via the Airflow UI
2. Save the connection successfully
3. Open the saved connection for editing
4. Click "Test" without re-entering the password
5. Observe in browser DevTools (Network tab -> Payload) that the POST body to /api/v2/connections/test contains password: "***"
6. Connection test fails with {status: false, message: "Authentication failed."}
7. Meanwhile, using the same stored password directly with Paramiko from inside the pod succeeds

Operating System

Debian 12 (container: apache/airflow:3.1.4)

Versions of Apache Airflow Providers

apache-airflow-providers-sftp==5.5.0
apache-airflow-providers-ssh==4.3.1
apache-airflow-providers-microsoft-azure==12.7.1
apache-airflow-providers-cncf-kubernetes==10.6.1
apache-airflow-providers-trino==6.3.3

Deployment

Official Apache Airflow Helm Chart

Deployment details

Official Apache Airflow Helm Chart

Deployed via helm upgrade --install airflow apache-airflow/airflow with custom values. Airflow 3.1.4 using KubernetesExecutor. The connection test endpoint /api/v2/connections/test is called from the React-based Airflow UI.

Anything else?

Workaround: Test connections from inside the pod using the CLI or direct Python/Paramiko, which correctly retrieves the stored password from the database:

from airflow.models import Connection
import paramiko

conn = Connection.get_connection_from_secrets('my_conn_id')
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(conn.host, port=conn.port or 22, username=conn.login, password=conn.password, look_for_keys=False, allow_agent=False)
sftp = ssh.open_sftp()
print('Connected:', sftp.listdir('.'))

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[vinitsingare]

From what I can see, the stored connection password is correct and works when retrieved via Connection.get_connection_from_secrets(), but when using the UI Test button, the masked placeholder value ("***") from the form is being sent in the request payload to /api/v2/connections/test.

The backend then treats this placeholder as a real password and attempts authentication with it, which naturally fails.

It seems the intended behavior should be that when the incoming password value is still the masked placeholder (i.e. the user has not changed the password), the test endpoint should ignore that value and instead reuse the stored password from the secrets backend. If the user explicitly re-enters a password, that value should be used instead.

I’m happy to work on this issue

[abhijeets25012-tech]

i would like to contribute

[jroachgolf84]

@vinitsingare - please feel free to open up a PR for this issue!

@abhijeets25012-tech, it looks like you've already got 4 other issues assigned to you :)