CDI scope/context in custom implementation of JWTCallerPrincipalFactory

[martin-kofoed-jyskebank-dk]

Hi,

I've implemented a custom JWT caller principal factory like mentioned in the RBAC documentation here, and I have experienced some weird behaviour that could be a bug - or at least something that should have a note in the docs.

I'm trying to propagate a user ID extracted from JWT claim after succesful validation for use in a @ServerRequestFilter. So I have declared a @RequestScoped bean to hold the user data. This bean is injected in my @ApplicationScoped JWT caller principal as well as in the server filter. I would expect it to be instantiated only once.

Instead, I see the following life cycle:

1. Custom JWT factory is instantiated
2. User data object is instantiated and populated
3. Server filter class instantiated
4. User data object instantiated once again, "overwriting" the first instance.

Is this expected behaviour? And if so: are there any other recommended ways to transfer data from a JWT factory down the stream?

Running Quarkus 3.16.4

Kind regards,
Martin

[quarkus-bot[bot]]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc), @sberyozkin (jwt)

[Ladicek]

Would you be able to create a small, self-contained reproducer? From the text, I myself cannot figure out where the problem can be.

[martin-kofoed-jyskebank-dk]

I made this simple reproducer:

https://github.com/martin-kofoed-jyskebank-dk/kofoed-jwt

Run quarkus dev and curl to localhost:8080/hello (or use REST Client for VS Code on file /rest/localhost.rest) with a Authorization Bearer test header to trigger JWT validation using custom factory.

But I think that the logs give away the answer here: the first instance of my @RequestScope bean is instantiated on vert.x-eventloop-thread-0. The one instantiated in the @ServerRequestFilter runs on executor-thread-1.

So this is most likely not a bug, more likely a CDI limitation gotcha.

[martin-kofoed-jyskebank-dk]

Nah, I tried annotating the API method with @NonBlocking to make everything run on the same thread. Same result.

[Ladicek]

Sounds like a context propagation issue then. I tried adding the quarkus-smallrye-context-propagation extension, but that didn't help (and I'm not sure we need that, it's only the CDI request context that we need propagated, and that should happen automatically via the Vert.x duplicated context, but I'm certainly no expert on that).