anonymous `SecurityIdentity` is not available inside background vertx worker, says "RequestScoped context was not active" about quarkus

[mkouba]

Judging from the changelog of 3.7.2, this might be a consequence of #38605

Looking at the pull request's description, my use-case was never legal and should have never worked to begin with. Would you agree @mkouba ?

@Felk That's correct. It only "worked" by coincidence.

[sberyozkin]

Also CC @manovotn @michalvavrik

[Felk]

Here's a reproducer project:
inject-securityidentity-regression.zip

It's basically just https://code.quarkus.io/?a=inject-securityidentity-regression&j=21&e=oidc&e=scheduler with the above code added.

[quarkus-bot]

/cc @sberyozkin (security)

[Felk]

Judging from the changelog of 3.7.2, this might be a consequence of #38605

Looking at the pull request's description, my use-case was never legal and should have never worked to begin with. Would you agree @mkouba ?

My solution would then be to catch ContextNotActiveException and treat that as an anonymous user.

[michalvavrik]

Hey, I'll let answer Martins on CDI request being active, but I have a comment on the use case if you don't mind.

I checked your reproducer and the identity is always going to be anonymous (even with active CDI request context), won't it? If so, I'm not sure why to bother, just use QuarkusSecurityIdentity.builder().setAnonymous(true).build(). I appreciate your real use case might be much more complex, but I can't imagine where the identity is coming from unless you set it yourself in the SecurityIdentityAssociation, in which case you need to do it inside same CDI request context in which you set it. Doesn't it basically means you need to do it inside scope of the same method where you request the identity (if you also want to be able to deactivate the context)?

I ask because if your real use case has non-anonymous identity that is accessible without the ContextNotActiveException, it should mean you had activated CDI request context in that scenario. So you can just activate it here as well.

[Felk]

My real-world usecase is that I have a @PreUpdate listener on JPA entities that sets a "updated_by"-kind of field on every update. That listener exists in all situations, including background workers, but also in the context of actual HTTP requests that do have a security context automatically. I didn't model any of that in the reproducer, so sorry if the reproducer looks a bit silly.

[michalvavrik]

My real-world usecase is that I have a @PreUpdate listener on JPA entities that sets a "updated_by"-kind of field on every update. That listener exists in all situations, including background workers, but also in the context of actual HTTP requests that do have a security context automatically.

Cool, that's legit scenario.

I didn't model any of that in the reproducer, so sorry if the reproducer looks a bit silly.

I just tried to understand, this is okay. Thank you

[Felk]

Alright, thanks for confirming! I'll close this issue