Closed tnsimon closed 11 months ago
Hello @tnsimon, I am open to supporting this use case and would gladly accept a PR with this feature. Thanks :)
One minor thing, is I would name the "prefix" option "scheme" to match how it's referred to in RFCs (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml).
Another idea that might be worth further thought is if we should look at a more generic way of adding additional headers to a request as others may have unique setups.
@zachomedia it would be possible to go with a nested structure. Though we would need to leave the X-API-Key implementation as is otherwise this would be a breaking change. The advantage here is being able to provide FieldName rather than hardcoding the Authorization
type authHeader struct {
SecretRef *cmmeta.SecretKeySelector `json:"secretRef"`
Scheme string `json:"scheme"`
FieldName string `json:"fieldName"`
}
type powerDNSProviderConfig struct {
// AuthHeader contains the secret reference information for the Kubernetes
// secret which contains the PowerDNS Auth token as well as the FieldName
// where the token will be set in requests.
AuthHeader *authHeader `json:"authHeader"`
}
@zachomedia would it be alright to tag and release this feature please? Thank you.
@tnsimon Yes, sorry, I've been busy the past couple of weeks and haven't been able to do the release. I'm hoping to do it tomorrow (Monday).
v2.5.0 was released on August 28 with this feature.
@zachomedia
I have a unique use case where PDNS is fronted by an ingress controller. The ingress accepts Authorization headers rather than the X-API-Key.
Would it be feasible if I submit a PR that adds support for this optional capability? The existing X-API-Key implementation would still exist. The new optional configuration would enable support for
Authorization: "Bearer {apiKey}"
The approach would add 2 optional configuration parameters