Skip to content
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

Support for data: URLs for loading resources #593

Open
MikeEdgar opened this issue May 2, 2022 · 5 comments
Open

Support for data: URLs for loading resources #593

MikeEdgar opened this issue May 2, 2022 · 5 comments

Comments

@MikeEdgar
Copy link
Member

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

@sberyozkin
Copy link
Contributor

@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 ?

@sberyozkin
Copy link
Contributor

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

@MikeEdgar
Copy link
Member Author

@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.

@sberyozkin
Copy link
Contributor

Hey @MikeEdgar Do you think we can keep this issue as a possible enhancement ?

@MikeEdgar
Copy link
Member Author

@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 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants