Persistence blocking call occurs in event-loop thread in @PreMatching filter

[sfc-gh-rliu]

Describe the bug

@PreMatching filters run on Vertx event loop threads. In some cases, we make a blocking call to persistence in a filter, hence blocking the event loop thread, which is strongly discouraged.

This occurs in

PolarisPrincipalAuthenticatorFilter 
PolarisPrincipalRolesProviderFilter

and potentially other filters.

To Reproduce

No response

Actual Behavior

No response

Expected Behavior

No response

Additional context

No response

System information

No response

[adutra]

Unfortunately it's not possible to annotate pre-matching filters with @Blocking, so we'll have to re-design the filters.

A possible solution would be to transform the incriminated filters into methods annotated with org.jboss.resteasy.reactive.server.ServerRequestFilter – as such methods are allowed to return a future, or a Uni.

[dimas-b]

ServerRequestFilter appears to be specific to Quarkus. If we go that way, why not use a proper Quarkus Authentication Mechanism plugin?

[adutra]

FYI I am working on a fix for this.

[adutra]

FYI, I think we should reopen this issue because there is one more problematic filter: RealmContextFilter. Since it invokes RealmContextResolver.resolveRealmContext(), the filter execution may block if the call to resolveRealmContext() blocks.

@dimas-b @sfc-gh-rliu wdyt?

[dimas-b]

DefaultRealmContextResolver appears to be non-blocking, so I'm not sure reopening this issue is justified, but it probably makes sense to fix RealmContextFilter to assume potentially blocking behaviour of RealmContextResolver. We could do that in a plain PR without an issue, though, WDYT?

[adutra]

We could do that in a plain PR without an issue, though, WDYT?

WFM, working on a fix for it.