Isn't it correct to say that route.guarded can be ignored and instead we only want to process all of the guards referenced by guard name in the expressions?

I think route.guarded entries contain pre-resolved identity and attribute functions set during config initialization. Bypassing them would require redundant guard resolution via EngineContext and lose route-specific guard configurations.

The concepts of guarded routes and guarded expressions are distinct.

Guarded routes are trying to make sure that zero or more specific roles are active for a valid session of a specific guard, such that the route is ignored if the session is invalid or the required roles are not active for the session. This is already handled by the engine, just the binding needs to ask the route to verify passing a valid session.

Guarded expressions are references to attributes of the session for a specific guard. It does not require any specific roles to be active. In each case we need the guard handler to resolve the guarded identity or guarded attribute expression.

The original mistake in the design was requiring guarded expressions on a route to only work on a guarded route, whereas this enhancement is to break that coupling, so that routes do not need to be guarded for guarded expressions to work.

So as part of these changes, we can verify that it is viable to remove the exposure of identity resolver and attribute resolver from the route as that can only be populated for guarded routes and therefore not relevant in the general case. As part of that removal we can also consider making it easier to obtain the guard handler by name instead of having to jump through so many hoops in the binding as it calls back into the engine context.

I attempted to simplify the code by always using EngineContext.supplyGuard() instead of checking route.guarded.identity or route.guarded.attributes first, but this caused integration test failures and AssertionErrors. For existing guarded routes, context.supplyGuard() returned null because the guards hadn’t been fully registered in EngineContext at that point in the lifecycle. This resulted in some existing test failures.

To resolve this, should we defer route-config construction until the EngineContext is fully populated?

@jfallows, please share your thoughts.

@nageshwaravijay1117 there was an issue with the guardId obtained from the guardName, so the lookup for GuardHandler then failed.

See de35c8a where I have made the necessary resolveId function available on the RouteConfig and used it from http-kafka to demonstrate tests passing without needing to use the guarded routes.

Please review and make corresponding changes to sse-kafka.

@jfallows verified the changes locally and updated the SSE-Kafka changes.