appsmithorg / appsmith

Platform to build admin panels, internal tools, and dashboards. Integrates with 25+ databases and any API.
https://www.appsmith.com
Apache License 2.0
34.19k stars 3.7k forks source link

[Feature]-[7568]:Edit auth API datasource, I don't know if client secret is saved or not #14783

Open rohan-arthur opened 2 years ago

rohan-arthur commented 2 years ago

Is there an existing issue for this?

Summary

When I edit an authenticated API datasource, I see the datasource form with all the fields filled, except the client secret. But now I don't know if the secret is actually saved or not, because the placeholder text is the same both in create and edit mode: Client Secret.

Screenshot 2022-06-24 at 08 01 31

When I edit a datasource, I should be able to distinguish the saved password/secret/etc fields from the ones where I have not entered anything

Why should this be worked on?

This simple fix should allay the user's anxiety and make the datasource editing experience better.

rohan-arthur commented 2 years ago

same issue with:

  1. Airtable, both for token and key
  2. MySQL password (but not, e.g., for mongo password)
  3. DynamoDB, AWS Secret Access Key
  4. MS SQL server, password
  5. Firestore Service Account Credentials
  6. Redshift, password
  7. S3, key
  8. Snowflake, password
  9. ArangoDB, password
rohan-arthur commented 2 years ago

event ROUTE_CHANGE, path containing 'edit/datasource', 6 months data: Total: 170,000 Unique: 10,300 i.e., about 86% of cloud users end up editing datarources

total 6m unique usage of all above datasources is 8,800. of these, 86% = 7568

Stats

Stat Values
Reach      7568
Effort (months)  0.5
prapullac commented 1 year ago

Issues : 1) Password is displayed to user before and after Saving the datasource on Dev tool

prapullac commented 1 year ago

The above mentioned issue still exists. However the main issue is resolved hence moving it to done state

PiyushPushkar02 commented 1 year ago

Re-tested it in my local once.

Moving this to Needs QA.

PiyushPushkar02 commented 1 year ago

Even after merging the release, there is still a build failure which is not reproducible locally. Will need more time to check this. Moving this ticket back to product backlog as we cannot close this without spending some extra time on the same. @rohan-arthur @sumitsum

rohan-arthur commented 3 months ago

Solution direction

Phase1: single plugin

  1. Let us pick any one plugin, say Postgres.
  2. In the datasource config page for postgres, there is the password field
  3. Here, create a datasource with username and password, and save it
  4. Open it for editing, you see that the password field is empty

Step 1: show a constant number of placeholder characters First as a simple implementation, only when the datasource is opened for editing, show 6 password mask characters when a password exists

(low priority)Step 2: show correct number of placeholder characters Once step 1 is working and looks good, the number of mask characters should be equal to the length of the password

Phase2: general solution for all plugins the implementation should work for all plugins, listed here

Nikhil-Nandagopal commented 3 months ago

@rohan-arthur the solution here seems unclear because if we simply show 6 characters and the user saves the datasource, the datasource will now be invalidated. So I'm questioning whether this issue is actually valid and we should just close it because I think we expect a user to re-enter any password credentials if they try to save a datasource

rohan-arthur commented 3 months ago

Thanks @Nikhil-Nandagopal I've added a clause to clarify above, "only when the datasource is opened for editing" I try to explain in this video

https://github.com/user-attachments/assets/2a517093-a376-40b8-b406-cf9a82a869b8

Nikhil-Nandagopal commented 3 months ago

@rohan-arthur I understand that but in this case we also need to handle the scenario where a user does not edit the password field but we still maintain the older password on the server.

rohan-arthur commented 3 months ago

@Nikhil-Nandagopal The user needs to know whether they have saved something in the secret fields. Masked characters is a widely understood convention, but even an indicator or an icon will do. It is not acceptable to leave the user in the dark about the configuration that they entered.

Screenshot 2024-07-15 at 18 22 50 Screenshot 2024-07-15 at 18 22 33 Screenshot 2024-07-15 at 18 22 12

ref screenshots from retool, budibase and superblocks.

Nikhil-Nandagopal commented 3 months ago

@rohan-arthur as I said it's fine to have the masked characters, my point is that in that event we also need to have a way to detect whether the password was edited or not and not update / update only that field