vigneshio commented on PR #4620: URL: https://github.com/apache/polaris/pull/4620#issuecomment-4631879692
Thanks @adutra, that makes sense. Since the broker is request-scoped, caching the verifier inside it still rebuilds one per request, so it doesn't actually save anything. Here's what I'm planning instead, wanted to check the approach with you before pushing: - Build the `Algorithm` and `JWTVerifier` in the `TokenBrokerFactory` implementations, cached per realm alongside the existing key/secret caches (the factories are already `@ApplicationScoped`), and pass the prebuilt instances into the broker. That way the verifier is built once per realm and reused across requests. - The two broker subclasses (`RSAKeyPairJWTBroker` / `SymmetricKeyJWTBroker`) currently differ only in how they build the `Algorithm`. Once that moves into the factories they'd be identical, so I was going to collapse them into a single `JWTBroker`. Let me know if you'd rather I keep them. One behavior change to flag: for the (uncommon) file-based symmetric secret, the secret would be read once per realm at first use rather than on every request. That's consistent with how the factory already caches per-realm material, but it means rotating the on-disk secret needs a restart. I think that's fine for a signing key, but happy to keep per-request re-reading for that case if you'd prefer (though that would mean the file-based path couldn't reuse the cached verifier). WDYT? If the approach looks good I'll push the update. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
