smallrye
Support for `data:` URLs for loading resources
Currently, the loading of resources is limited to file, https, and classpath URLs [1]. It would be useful to also support data URLs [2] as well. In a cloud environment, this would allow us to directly specify resources via env (from secrets) instead of mounting the secrets as volumes and mapping to files.
For example, the configuration could be set to:
smallrye.jwt.client.tls.certificate.path=data:,${my.pem.encoded.ca-cert}
Allowing the secret to be mapped to env MY_PEM_ENCODED_CA_CERT and loaded by the implementation.
[1] https://github.com/smallrye/smallrye-jwt/blob/main/implementation/common/src/main/java/io/smallrye/jwt/util/ResourceUtils.java#L64 [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs
@MikeEdgar Hi Mike, would it really be about supporting arbitrary URL schemes for https://github.com/smallrye/smallrye-jwt/blob/main/implementation/common/src/main/java/io/smallrye/jwt/util/ResourceUtils.java#L81 to work ? But that would require supporting the injection of such resolvers and passing them around in JwtAuthContextInfo.
Perhaps, for now, a simpler alternative is to introduce smallrye.jwt.client.tls.certificate which would be similar to how the verification public key can be either inlined or fetched from some .location ?
if you agree with the smallrye.jwt.client.tls.certificate idea then we can still track the option of supporting custom URL schemes with this issue
@sberyozkin I think the suggestion to have smallrye.jwt.client.tls.certificate is good. I spent a little time looking into the data: URL and there is actually some complexity around the payload being URL-encoded which reveals it may not be viable for this use case.
Hey @MikeEdgar Do you think we can keep this issue as a possible enhancement ?
@sberyozkin , no objection from me to keep it open. There could be cases where it's useful, although #596 was exactly what I needed at the time :smile: