3.0.0: config/reuse_detection.php passes a %parameter% placeholder as a service id → container build fails ("non-existent service")

[sanchobouillant]

Version: gesdinet/jwt-refresh-token-bundle 3.0.0 · Symfony 8.1.5 · PHP 8.4/8.5

Summary

Enabling reuse_detection makes the container compilation fail:

The service "gesdinet_jwt_refresh_token.spent_refresh_token_registry" has a dependency on a non-existent service "%gesdinet_jwt_refresh_token.reuse_detection.cache%".

Cause (read in the source)

config/reuse_detection.php designates the cache pool with service((string) param('gesdinet_jwt_refresh_token.reuse_detection.cache')), i.e. a literal %…% string used as a service id. Symfony's ResolveParameterPlaceHoldersPass resolves placeholders in strings, definitions and aliases, but not inside a Reference — so the reference is looked up verbatim. The inline comment ("turned into the %name% placeholder service() takes") relies on a behaviour Symfony 8 (and, as far as we can tell, earlier versions) does not have.

Reproduction

gesdinet_jwt_refresh_token:
    refresh_token_class: App\Entity\RefreshToken
    single_use: true
    reuse_detection:
        enabled: true
        cache: cache.app

php bin/console lint:container → error above.

Workaround

Redefine the service in the application with the concrete pool:

services:
    gesdinet_jwt_refresh_token.spent_refresh_token_registry:
        class: Gesdinet\JWTRefreshTokenBundle\...\CacheSpentRefreshTokenRegistry
        autowire: false
        autoconfigure: false
        arguments: ['@cache.app', '%gesdinet_jwt_refresh_token.reuse_detection.ttl%']

Note for anyone applying it: the reuse_detection.* parameters only exist while reuse_detection.enabled is true (GesdinetJWTRefreshTokenExtension.php:99-111), so this override must be removed when the option is disabled, otherwise ParameterNotFoundException.

Suggested fix

Resolve the parameter in the extension and pass a proper Reference (e.g. new Reference($config['reuse_detection']['cache'])), or use an alias.

Related: #<see companion issue on hash_tokens × reuse_detection>.

[sanchobouillant]

Companion issue (same version, same feature): #433 — reuse_detection is inert when hash_tokens is enabled.

[twispr]

Confirmed on v3.0.0 (PHP 8.5, Symfony 8.1). Same root cause, but the pattern is not limited to config/reuse_detection.php.
The identical service((string) param(...)) call is present in four config files:

• config/reuse_detection.php
• config/rate_limiter.php
• config/block_jwts_on_revocation.php
• config/cache_services.php

With rate_limiter.enabled: true the container fails the same way:

The service "gesdinet_jwt_refresh_token.refresh_rate_limiter" has a dependency on a
non-existent service "%gesdinet_jwt_refresh_token.rate_limiter.limiter%".

(string) param(...) produces the literal %name% placeholder, and Symfony's ResolveParameterPlaceHoldersPass does not resolve placeholders inside a Reference id. So any of these features is unusable out of the box.

A fix probably wants to avoid the parameter indirection entirely. The extension already knows the configured service id when it processes the config. So the argument can be set as a real Reference there instead of round-tripping through a container parameter. Whatever shape it takes, it should cover all four files.

Workaround meanwhile (same idea as the OP's, for the two services we use):

gesdinet_jwt_refresh_token.refresh_rate_limiter:
    class: Gesdinet\JWTRefreshTokenBundle\Security\RateLimiting\RefreshRateLimiter
    arguments:
        - '@limiter.refresh'                                  # configured limiter
        - '%gesdinet_jwt_refresh_token.rate_limiter.key%'
gesdinet_jwt_refresh_token.spent_refresh_token_registry:
    class: Gesdinet\JWTRefreshTokenBundle\Security\ReuseDetection\CacheSpentRefreshTokenRegistry
    arguments:
        - '@cache.app'                                        # configured pool
        - '%gesdinet_jwt_refresh_token.reuse_detection.ttl%'