Introduce a templating system to base64 encode variables#352
Conversation
isabella-garza-datadog
left a comment
isabella-garza-datadog
left a comment
There was a problem hiding this comment.
Instead of denoting the encoding in the key name, I noticed there's already a comment in config_v2.rs (link) that suggests using an inline function syntax in the value instead:
/// Example: {"Authorization": "Basic %base64($CLIENT_ID:$MATCH)"}
I think that reads a bit more naturally since the transformation is right where the encoding happens and we don't need to strip the suffix from the key name. What do you think about using that approach instead?
|
The syntax that's documented here would definitely be better! |
Taiki-San
changed the title
isabella-garza-datadog
left a comment
isabella-garza-datadog
left a comment
There was a problem hiding this comment.
Thanks for making the changes and the exhaustive tests! Just left a few small suggestions
isabella-garza-datadog
left a comment
isabella-garza-datadog
left a comment
There was a problem hiding this comment.
LGTM overall! Left one last small comment 😸
2 participants
This PR introduce support for a syntax enabling base64 encoding parts of a request. This is helpful to support Basic Auth which involved base64 encoding the username and password to authenticate the request.
The syntax look like
%base64(arbitrary_string). Variables can be used in the transformation (%base64($MATCH)) but can't contain transformation instruction ($MATCH=>%base64(bla)will be escaped and rendered literally).The engine ignore unknown instructions (for instance, URL encoded strings)