Bug #23230
open
Workbench should validate scopes when creating/updating an external credential
Description
As of 3.2.0, railsAPI validates scopes based on supported credential classes using reserved namespaces. Currently the only supported credential class is "arv:aws_access_key". When creating or updating an external credential, if a user enters values that conflict with what we support, the user won't know it until they submit the form and see the API error toast. At that point, all of the values they've entered are lost. Workbench should validate errors on typing using the following flowchart:
- If credential_class equals arv:aws_access_key, validate that scopes contains one or more strings that all match the case-insensitive regexp ^s3://(\*|[a-z0-9][-.a-z0-9]{1,61}[a-z0-9])$ (see S3 bucket naming rules use the special bucket name
*to mean "all buckets") - Otherwise, if credential_class starts with arv:, show a message like `credential_class ${name} is not implemented`
- Otherwise, if credential_class equals aws_access_key, show a message like `credential_class ${name} conflicts with reserved credential class arv:${name}`
When invalid values are present, an error should be shown in red text below the offending input. The submit button should be disabled until all values are valid.
Updated by Lisa Knox 5 months ago
- Related to Feature #23210: Stricter validation of credential_class and scopes on credentials added
Updated by Brett Smith 5 months ago
So I do agree that the implementation suggestion would get us the best UX. However, I'm concerned about how much code it's duplicating, that we have to keep in sync forever, and opening the door to bugs where the implementations are slightly different.
As a starting point, how doable is this?
- When you submit a new credential, the dialog waits for a response before closing.
- If Workbench gets an error response back, it shows the error in a toast or similar popup, then re-enables the submit button. It retains all your inputs so you can try again.
- If Workbench gets a success response, it closes the dialog and renders the update as now.
One nice thing about this approach is it helps with errors besides validation, like "oops my wifi just cut out" or whatever.
Longer-term, what might be cool is if we offered a "prevalidation" method in the Arvados API, so you could submit a proposed update to the API server and it would tell you what the response would be without actually committing it to the database. This way Workbench could proactively let the user know about problems without duplicating validation code. We could even make sure to structure the error response in such a way that Workbench could give useful guidance to the user on specific inputs; i.e., this specific field had these specific problem(s). That would also be useful for clients other than Workbench.
Updated by Lisa Knox 5 months ago
As a starting point, how doable is this?
So it looks like this is already the pattern we use for duplicate name validation and a few other reasons. I see no reason not to apply this pattern to credentials.
As far as the dry-run validation goes, every field (at least for credentials, I'm not 100% on other models) is validated at the API level at minimum. For certain fields there is DB validation as well. Sending a request that gets rejected at the API level (and therefore never makes it to the DB insertion attempt) takes the same amount of time as the dry-run would, so I'm not seeing an advantage there.