-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Refactor raw PKI fetch endpoints #14813
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have comments, but this is 100% better than what it was, so whatever.
// Returns the CA chain | ||
func pathFetchCAChain(b *backend) *framework.Path { | ||
return &framework.Path{ | ||
Pattern: `(cert/)?ca_chain`, | ||
Pattern: `cert/ca_chain`, | ||
|
||
Callbacks: map[logical.Operation]framework.OperationFunc{ | ||
logical.ReadOperation: b.pathFetchRead, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this one in particular not using a helper? I'm not sure why the serial is still set in the switch case statement there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was only handling the non-JSON ("raw") responses in this PR. :-) This endpoint (cert/ca_chain
) returns a JSON blob, so I didn't touch it on this first pass.
@@ -315,6 +333,79 @@ reply: | |||
return | |||
} | |||
|
|||
func (b *backend) readCertByAlias(ctx context.Context, req *logical.Request, alias string) ([]byte, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems to duplicate what is already in pathFetchRead: is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes; if we later refactor the JSON endpoints, we'll refactor pathFetchRead
and likely use this logic instead of the logic already in it.
I didn't really see value in updating pathFetchRead
to take out this piece of logic (avoiding the duplication) for the time being, since the bigger refactor of JSON endpoints would probably impact how we structure it anyways.
That's my 2c. at any rate.
Various endpoints (/ca, /crl, /ca_chain, /certs) all use the same core handling logic with a complicated per-path detection logic of which to return. Refactor out the common response formatting code, but let each API handler be distinct to provide the right storage reference. This refactors just the raw path (/ca, /crl, /ca_chain, and /cert/*/raw{,/pem}). Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
58d5b41
to
1d06b27
Compare
This approach won't work, because the Framework logic doesn't understand paths created this way. Closing this. |
Various endpoints (
/ca
,/crl
,/ca_chain
,/certs
) all use the same corehandling logic with a complicated per-path detection logic of which to
return. Refactor out the common response formatting code, but let each
API handler be distinct to provide the right storage reference.
This refactors just the raw path (
/ca
,/crl
,/ca_chain
, and/cert/*/raw{,/pem}
).Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
This should be rebased and merged after #14767 probably. We'll want a second version for the non-raw endpoints, but this at least takes a step in the right direction.