Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Response Structures to PKI Config #18376

Merged
merged 38 commits into from
Feb 15, 2023
Merged

Conversation

AnPucel
Copy link
Contributor

@AnPucel AnPucel commented Dec 14, 2022

Adding Response Structures to PKI Config. Corresponding response structures are linked below each file name

Please see this RFC for implementation details.

Path Tested
config/ca yes
config/issuers yes
root/replace none
config/keys none
config/cluster yes
config/crl yes
config/urls yes

Related PRs:

@AnPucel AnPucel requested a review from a team December 14, 2022 19:58
@cipherboy cipherboy requested a review from a team December 14, 2022 20:34
@dhuckins
Copy link
Contributor

@AnPucel can you provide a link (either to docs or source code) to what you're using as references for the fields?

@AnPucel
Copy link
Contributor Author

AnPucel commented Dec 15, 2022

@AnPucel can you provide a link (either to docs or source code) to what you're using as references for the fields?

I mostly followed the callback and looked at the structure of the response that was being returned there. So, it's a little tedious, but they're usually in the same file.

Copy link
Contributor

@averche averche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable to me, though I only spot checked some fields.

builtin/logical/pki/path_config_urls.go Outdated Show resolved Hide resolved
builtin/logical/pki/path_config_crl.go Outdated Show resolved Hide resolved
Description: "OK",
Fields: map[string]*framework.FieldSchema{
"expiry": {
Type: framework.TypeString,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[note]
lots of these fields are durations, maybe we can add a format field to framework.FieldSchema eventually to make it more explicit
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.1.md#data-types
https://pkg.go.dev/github.com/go-openapi/strfmt#section-readme

Copy link
Contributor

@cipherboy cipherboy Dec 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have TypeDurationSecond, but I don't know if the response is formatted correctly for that always?

Sometimes there are also string time.Time value when its a concrete date instead of a duration though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, since we have the tests now, would it be possible to try it out with TypeTime and TypeDurationSecond?

case TypeTime:
ret.baseType = "string"
ret.format = "date-time"

case TypeDurationSecond, TypeSignedDurationSecond:
ret.baseType = "integer"
ret.format = "seconds"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment applies to:

  • auto_rebuild_grace_period
  • ocsp_expiry
  • delta_rebuild_interval
  • expiry

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! I did update this on a few other PRs. So, I forgot to go back and do it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With regard to this, the user sees these as string, e.g. 15m and then it gets parsed into a duration when it's handled. Shouldn't it reflect what the user sees or should it be a duration?
https://developer.hashicorp.com/vault/api-docs/secret/pki#expiry

builtin/logical/pki/path_config_ca.go Show resolved Hide resolved
Co-authored-by: Anton Averchenkov <[email protected]>
},
"enable_templating": {
Type: framework.TypeBool,
Description: `Whether or not to enable templating of the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to reuse descriptions of response/parmas especially for these configs, but we can do the refactoring after this merges.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! That works for me. I tried to keep them consistent. I can definitely update these with better ones after the fact.

@AnPucel AnPucel added this to the 1.13.0-rc1 milestone Jan 9, 2023
Copy link
Contributor

@averche averche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the tests! Left a couple comments, otherwise LGTM

Description: "OK",
Fields: map[string]*framework.FieldSchema{
"expiry": {
Type: framework.TypeString,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, since we have the tests now, would it be possible to try it out with TypeTime and TypeDurationSecond?

case TypeTime:
ret.baseType = "string"
ret.format = "date-time"

case TypeDurationSecond, TypeSignedDurationSecond:
ret.baseType = "integer"
ret.format = "seconds"

Description: "OK",
Fields: map[string]*framework.FieldSchema{
"expiry": {
Type: framework.TypeString,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment applies to:

  • auto_rebuild_grace_period
  • ocsp_expiry
  • delta_rebuild_interval
  • expiry

@AnPucel AnPucel modified the milestones: 1.13.0-rc1, 1.14 Feb 13, 2023
Copy link
Contributor

@averche averche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

This was referenced Feb 15, 2023
@AnPucel AnPucel merged commit d09e02a into main Feb 15, 2023
@AnPucel AnPucel deleted the anpucel/PKIResponseStructures branch April 4, 2023 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants