[DSIP-101][ApiServer] How should the password be handled more elegantly when editing a data source?

[njnu-seafish]

Search before asking

• I had searched in the DSIP and found no similar DSIP.

Motivation

When editing a data source, the password field returned by the backend is masked as "*****". If the user does not change the password, the backend treats this mask as the plaintext password entered by the user during testing and saving.

The current implementation is prone to accidentally overwriting the data source's password.

Design Detail

Option 1: Add connectivity validation when saving the data source.

Option 2: If the user has not modified the password (i.e., the frontend sends the masked value "*****"), the backend should not treat this mask as the actual password provided by the user.

Option 3: When editing a data source, the password field should be left blank instead of displaying a mask (e.g., "*****").

Option 4: Separate the password modification action from the modification of other data source information.

Compatibility, Deprecation, and Migration Plan

No response

Test Plan

No response

Code of Conduct

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

[njnu-seafish]

@SbloodyS @ruanwenjun Thanks so much, folks! Please take a look at this issue when you have time.

[SbloodyS]

I would prefer the first option. And just like wenjun's comment in #17811 (comment)

We can provides a global switch for users whether to turn on API datasource verification.

[det101]

To improve security and the user experience, editing a data source should not provide a password modification form or touch password updates in the backend. Password changes must have a separate entry and interface where users enter the current password and new password, and the backend only updates after verifying the current password. This prevents accidental password changes and adds an extra layer of security.

[ruanwenjun]

Having a separate button just for changing passwords isn't very good, it's hard to check the datasource other param.
One effective approach I can think of is to return an empty password field each time, meaning the interface never returns the password. Whenever the data source is updated, the password must be re-entered.

[det101]

Having a separate button just for changing passwords isn't very good, it's hard to check the datasource other param. One effective approach I can think of is to return an empty password field each time, meaning the interface never returns the password. Whenever the data source is updated, the password must be re-entered.

@ruanwenjun @SbloodyS

1. The frontend does not display sensitive field content if the backend does not return it.
2. A switch has been added to control whether forced verification of connection test results is saved. This is disabled by default, meeting the need for strict control over data source modifications.