Take paths instead of base64 for SAML creation#1112
Conversation
Currently the CLI's SAML IdP creation flow does not provide flags for signing keys, requiring the cryptic `--json-body` argument. These and the XML metadata must be manually base64-encoded by the user as well. Make this process more convenient by converting the keys and XML metadata args to take the path of the source files, which we then read and encode ourselves. While we're at it, hide the no longer needed `--json-body` and `--json-body-template` arguments in the CLI and stop generating docs for hidden items. Example command: ``` $ oxide silo idp saml create \ --silo cli \ --name "keycloak" \ --description "Keybloke" \ --sp-client-id cli \ --acs-url "https://cli.sys.example.com/login/cli/saml/keycloak" \ --idp-entity-id "https://keycloak.example.com/realms/cli" \ --slo-url "" \ --technical-contact-email "user@example.com" \ --group-attribute-name group --metadata-path ./cli-metadata.xml \ --public-cert-path ./cli-cert.der \ --private-key-path ./cli-key.der \ ```
| .mut_arg("json-body", |arg| arg.required(false).hide(true)) | ||
| .mut_arg("json-body-template", |arg| arg.hide(true)) |
There was a problem hiding this comment.
We show these for all commands that take bodies, even if they're not required. What's the motivation here?
There was a problem hiding this comment.
I find json-body confusing, personally, and I had the impression we wanted to move away from it.
There was a problem hiding this comment.
We want to move away from requiring it; I don't think we want to move away from supporting it. What do you find confusing?
There was a problem hiding this comment.
Ah OK, my mistake. Mostly it's not obvious when --json-body is required, and how it composes with the rest of the command. If I set a value in JSON and as an argument, which one wins? Are there fields that can only be set via JSON?
There was a problem hiding this comment.
Let's write those things down
There was a problem hiding this comment.
Where? Ideally it ends up in the error message when you use them incorrectly. Maybe even in the non-error help output, if it's not too long.
These are platform-dependent.
ahl
left a comment
ahl
left a comment
There was a problem hiding this comment.
thanks for adding the test!
| let mut args = cmd | ||
| .get_arguments() | ||
| .filter(|arg| arg.get_long() != Some("help")) | ||
| .filter(|arg| !arg.is_hide_set()) |
There was a problem hiding this comment.
this is fine, but is it still relevant?
There was a problem hiding this comment.
I think it's worth leaving in to stop documenting the --parallelism argument
| .arg("http://nope.nope") | ||
| .arg("--technical-contact-email") | ||
| .arg("anyone@but.adam") | ||
| .arg("--private-key") |
There was a problem hiding this comment.
this fails because this guy didn't have his friend?
There was a problem hiding this comment.
Yup, that's correct. Do you want a comment here to be explicit?
There was a problem hiding this comment.
I'm thinking of myself in the future, breaking this, but not noticing.
Customers have found it inconvenient and error-prone to pass in the contents of certs and keys to the `certificate create` subcommand. To make this command easier to use, update its `key` and `cert` arguments to be treated as the path to their respective files, rather than their contents. We previously updated the SAML IdP creation command the same way with 11fe44b (Take paths instead of base64 for SAML creation (#1112), 2025-05-28).
Customers have found it inconvenient and error-prone to pass in the contents of certs and keys to the `certificate create` subcommand. To make this command easier to use, update its `key` and `cert` arguments to be treated as the path to their respective files, rather than their contents. We previously updated the SAML IdP creation command the same way with 11fe44b (Take paths instead of base64 for SAML creation (#1112), 2025-05-28). Co-authored-by: Adam Leventhal <ahl@oxide.computer>
3 participants
Currently the CLI's SAML IdP creation flow does not provide flags for signing keys, requiring the cryptic
--json-bodyargument. These and the XML metadata must be manually base64-encoded by the user as well.Make this process more convenient by converting the keys and XML metadata args to take the path of the source files, which we then read and encode ourselves.
While we're at it, stop generating docs for hidden items.
Example command: