The UserRequirementsConditionChecker does two things currently. It parses the condition, which may be compound, and evaluates a set of core conditions.

OATHAuth defines also its own condition checker, which can make assumptions about 2FA status, so that it can be determined, whether user is obliged to have 2FA enabled. In practice it only needs to override how the atomic conditions are evaluated, but for that it has to extend the full class, which includes a lot of unrelated logic.

In this setting, adding new conditions to core (and thus, adding new dependencies in constructor) will require updating the OATHAuth's ServiceWiring. It's very easy to oversee this and block some CIs or start triggering logspam on prod.

Idea

The UserRequirementsConditionChecker is split into two classes – one responsible for going through compound conditions, and managing the general syntax of them. The second class will support the atomic conditions already defined in core.

In such scenario, the top-level condition checker will be created with an array of atomic condition checkers, so that adding new conditions won't require fundamental and possibly breaking changes to the whole object. OATHAuth will be then able to create the condition checker with a custom set of evaluators.