Closed bart-jansen closed 2 months ago
Thanks @bart-jansen! If I've understood correctly, the goal here to allow a generator (or forwarder) to have a different auth scheme to the existing api-key
implementation?
The existing approach isn't great as it requires the validate_api_key
method to be updated to add new auth schemes. I wonder whether it would be better to split the functionality of the validate_api_key
out and then call it from the relevant generator/forwarder endpoints? That way any future auth approaches can be added directly in the relevant generator/forwarder extension code
The recent refactorings (e.g. #32) have changed how auth works. It is now the responsibility of the generator to add auth, opening up the ability to add custom auth in an extensions. I believe this addresses the requirement from this PR
Custom generators/forwarders don't necessarily have an
api-key
orocp-apim-subscription-key
header set.This PR allows you to specify a custom bearer token to pass the
validate_api_key()
and send a response