fix(cache): apply cache.redis.password and redis.use.ssl on every Redis connection

[hongwei1]

Problem

code/api/cache/Redis.scala reads cache.redis.password and redis.use.ssl, but not every connection path applied them. Two gaps, both of which only surface once an operator actually hardens Redis:

1. The memoize cache ignored the password (and TLS).

jedisPool passes both settings, and is what rate limiting, idempotency, the health check and Redis.use lease from. But the memoize store was built separately:

implicit val scalaCache = ScalaCache(RedisCache(url, port))

scalacache-redis 0.9.3's RedisCache.apply(String, int) constructs its own internal JedisPool with no password and no SSL. That store backs memoizeWithRedis / memoizeSyncWithRedis, which serve Caching.memoizeWithProvider / memoizeSyncWithProvider — the main API caching layer, including connector result caching (31 call sites across 22 files).

With requirepass enabled, that path fails with NOAUTH while performStartupHealthCheck() — which leases from jedisPool — still logs Redis health check PASSED. The failure surfaces only as cache misses and a performance collapse, with clean-looking logs.

2. The pub/sub subscribers ignored TLS.

ChatEventBus, LogCacheEventBus and MetricsEventBus each built their subscriber connection with the plaintext Jedis(url, port, timeout) constructor. They authenticated explicitly, so the password was applied, but redis.use.ssl was silently dropped: with TLS on, the pool and the memoize cache spoke TLS while these three streaming buses tried to connect in plaintext.

Fix

Memoize store — reuse the pool that already has both settings:

implicit val scalaCache = ScalaCache(RedisCache(jedisPool))

The RedisCache(JedisPool, Option[ClassLoader]) overload resolves with its default second argument.

Subscribers — they genuinely cannot lease from jedisPool, since subscribe/psubscribe occupy their connection for the life of the subscription. Rather than have each call site reassemble the connection settings, add Redis.newSubscriberConnection(), which applies the same password and TLS configuration the pool uses, and have the three buses call it. sslContext becomes a lazy val so the keystore and truststore are read once, and only when redis.use.ssl is on.

Docs — sample.props.template now lists redis.use.ssl alongside cache.redis.password in the Redis block, and notes that the 127.0.0.1 default is a deliberate security default: Redis should not be bound to a public interface.

Verification

Against a local requirepass-protected Redis:

Scenario	Before	After
memoize round trip	never caches — every call recomputes, 0 keys written (silent NOAUTH)	caches; second call served from Redis

Against a local TLS-only, requirepass-protected Redis (self-signed CA; the port rejects plaintext):

Scenario	Before	After
subscriber connect + pub/sub round trip	JedisConnectionException: Connection reset	authenticates and delivers the message

No-password and no-SSL defaults are unchanged: a null password still yields an unauthenticated connection, and MethodRoutingCacheInvalidationTest + RedisDeserializeMissTest (5 tests, exercising the memoize path against a passwordless Redis) pass.

All connection construction sites were audited (new JedisPool, new Jedis, RedisCache(, JedisPubSub): the pool, the memoize store, the three subscribers, and RedisMessaging / RedisLogger / ConnectorMetricsRedis (all of which already go through the pool). The cache-config endpoint exposes only url, port and use_ssl — never the password.

CI is green on both commits (9 test shards + compile + docker).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud