Redis-based throttle rate limiting generates non-namespaced keys, breaking Redis ACL compatibility

[lordcoste]

Laravel Version

12.43

PHP Version

8.3

Database Driver & Version

No response

Description

When using Redis-native rate limiting (via ThrottleRequestsWithRedis), the throttle middleware generates Redis keys without a stable namespace.

The key generation logic lives in ThrottleRequests::handle() and produces keys based on the request signature (hashed identifier), which results in raw, unhaspaced Redis keys (e.g. SHA-1 hashes).

While this works in unrestricted Redis environments, it breaks in Redis installations where ACLs are enforced using key patterns (common in managed Redis / Valkey services).

In such environments, Redis-native throttling fails with:

NOPERM No permissions to access a key

even when all required Redis commands (including EVAL) are explicitly allowed.

This behavior is inconsistent with other Redis-backed features in Laravel (cache, queue, session), which always use namespaced keys (laravel:, queues:*).

Additional context

The throttle middleware already supports a $prefix argument, which is concatenated to the generated key in ThrottleRequests::handle().

However, this prefix is designed for logical separation of rate limiters at the route level (e.g. distinguishing different limits on the same endpoint), not as a stable infrastructure-level namespace.

Because the prefix is optional, route-specific, and user-provided, it cannot be reliably used to ensure compatibility with Redis ACLs based on key patterns.

For comparison, using the cache-based throttle middleware (ThrottleRequests) with Redis configured as the cache driver works correctly in the same ACL-restricted Redis environments, as cache keys are properly namespaced via the cache prefix.

Possible improvement

Providing a stable, overrideable namespace for Redis-based rate limiter keys would make the middleware compatible with Redis ACLs while preserving backward compatibility.

For example, this could be achieved by introducing a protected method that returns an optional infrastructure-level key prefix (defaulting to an empty string), which would be prepended to the generated throttle key.

This approach would preserve existing behavior by default, while allowing applications running in ACL-restricted Redis environments to safely namespace rate limiter keys.

Steps To Reproduce

1. Create a new Laravel application.

2. Configure Redis as the backend for rate limiting and enable Redis-native throttling
   (i.e. use ThrottleRequestsWithRedis).

3. Configure Redis/Valkey with ACLs that restrict access by key pattern, for example:

   • Allow all commands required by Redis-based throttling (including EVAL).
   • Allow access only to keys matching a specific prefix (e.g. throttle:* or laravel:*).

4. Apply the throttle middleware to a route:

   Route::middleware('throttle:5,1')->get('/test', fn () => 'ok');

5. Send a request to the route.

6. Observe that Redis immediately returns the following error:
   NOPERM No permissions to access a key

7. Inspect the Redis key used by the throttle middleware: it is a raw hash without a namespace
   and therefore does not match the allowed ACL key patterns.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[yugarinn]

I tracked down the issue to this eval call in the DurationLimiter::acquire method.

The Lua script is trying to acquire a lock for the rate limiter key with a prefix of laravel-database-{hash}, which is not permitted by the rules set in your users.acl example. In my testing, changing the Redis throttle user ACL permissions pattern from laravel:* to a wider laravel* does the trick, since that matches the laravel-database-{hash} pattern.

Whether or not the prefix set by Laravel for that key is "correct" is beyond my knowledge.

[dxnter]

When using ThrottleRequests, keys go through the cache layer and get cache.prefix applied, since it operates through Laravel's cache system.

When using ThrottleRequestsWithRedis, you're opting into Redis-native rate limiting, so keys follow Redis conventions instead. The Redis connection prefix (database.redis.options.prefix) is already applied automatically.

As @yugarinn identified, the issue is a mismatch between your ACL pattern (laravel:*) and Laravel's default REDIS_PREFIX ({app_name}-database-).

To resolve this, you could set REDIS_PREFIX in your environment to match your existing ACL pattern.

---

This behavior is inconsistent with other Redis-backed features in Laravel (cache, queue, session), which always use namespaced keys (laravel:, queues:*).

Higher-level abstractions like RedisStore and RedisBroadcaster do apply their own application-level prefixes. However, lower-level primitives like DurationLimiter, ConcurrencyLimiter, and RedisLock don't. They expect the caller to handle prefixing if needed.

For example, RedisLock doesn't apply any prefix itself. When used through RedisStore, the store pre-prefixes the lock name before passing it in. My assumption is that this was an intentional design decision to keep the primitives flexible for direct Redis usage, while letter higher-level abstractions add their own namespacing.

ThrottleRequestsWithRedis follows this same pattern. It's a Redis-native operation that relies on the Redis connection prefix rather than layering on a cache style prefix.

[HeathNaylor]

I have a possible fix for this written but want to make sure we need this before opening a PR.

ThrottleRequestsWithRedis is a higher level abstraction (middleware), not a low-level utility. Other higher level abstractions in the framework add their own namespace before delegating to lower level classes, for example RedisStore pre-prefixes lock names before passing them to RedisLock, and RedisQueue hardcodes 'queues:' in getQueue().

Since queues are already handled this way we could add a protected keyPrefix() method to ThrottleRequestsWithRedis that returns 'throttle:' by default applied to the key before it's passed to DurationLimiter. This would keep DurationLimiter unchanged while giving throttle keys a namespace like how 'queues:' works. The method is protected so it can be overridden if needed.

As @dxnter said, the Redis connection prefix is already applied at the connection level. This would add a prefix on top of that, resulting in keys like {redis_prefix}throttle:{hash} — making ACL patterns like throttle: work.

Since this changes the key default, it would target master rather than 12.x. as it is a breaking change.

[HeathNaylor]

This was rejected for a merge. I think we should either identify the underlying reason for the rejection or remove the help wanted label / close this issue. The underlying problem can be solved by just extending ThrottleRequestsWithRedis and overriding the key there anyway.

[lordcoste]

Thanks for the investigation.

Just to add some context: in production we resolved this by extending
ThrottleRequestsWithRedis and explicitly adding a throttle: prefix to the
generated key. This fixed the issue without widening Redis ACL key patterns.

The intent of the issue was mainly to highlight an inconsistency with other
Redis-backed features in the framework. Cache, queue, and similar components
use explicit, intentional namespaces, while Redis-native throttling currently
relies on raw keys or implicit client-level prefixes.