While this is a basic setup for this now, i wonder if we are OK with this as is.

What's Missing in current Implementation (yet)

1. Named Rate Limiters

Laravel and Symfony both support named limiters that can be reused:

  // Missing in CakePHP - would need:
  RateLimiter::define('api', [
      'limit' => 100,
      'window' => 60,
  ]);

  // Then use:
  ->add(new RateLimitMiddleware('api'))

2. Route Attributes/Annotations

Symfony supports attributes on controller methods:

  // Missing in CakePHP - would need:
  #[RateLimit(limit: 5, window: 300)]
  public function login() { }

3. Retry-After Header

Both frameworks automatically add Retry-After header:

  // Should add to our implementation:
  if (!$result['allowed']) {
      $response = $response->withHeader('Retry-After', $result['reset'] - time());
  }

4. Hit Callback

Laravel supports callbacks when limit is hit:

  RateLimiter::for('api', function (Request $request) {
      return Limit::perMinute(60)->by($request->user()->id)
          ->response(function () {
              return response('Custom response...', 429);
          });
  });

5. Distributed Rate Limiting

Laravel has built-in support for distributed systems:

  return Limit::perMinute(1000)
      ->by($request->user()->id)
      ->distributed(); // Uses Redis EVAL for atomic operations

6. Rate Limit Events

Laravel fires events when limits are hit:

  Event::listen(RateLimitExceeded::class, function ($event) {
      Log::warning('Rate limit exceeded', [
          'key' => $event->key,
          'limit' => $event->limit,
      ]);
  });

7. Grace Period

Some implementations support grace periods:

  'limit' => 60,
  'window' => 60,
  'grace_period' => 10, // Allow 10% over limit before hard stop

8. IP Whitelisting

Built-in IP whitelist support:

  'whitelist' => ['127.0.0.1', '192.168.1.0/24'],

Critical Missing Features

The most critical missing features are:

1. Retry-After Header - Standard HTTP practice
2. Distributed/Atomic Operations - Important for scaled applications
3. Named/Reusable Limiters - Better configuration management
4. Events/Logging - Important for monitoring and alerting

Just a FYI, there's https://github.com/UseMuffin/Throttle

This is more to get an idea of General 1st level Support of this security topic within the framework directly
Also what kind of the above features would be good to have. Then we can go into details and also clarify those.
Indeed, it should be more general by default.

Retry-After Header - Standard HTTP practice
Distributed/Atomic Operations - Important for scaled applications
Named/Reusable Limiters - Better configuration management
Events/Logging - Important for monitoring and alerting

Retry-After header and events are something that should be present in the initial release. Other features could be added later.

Compared to Throttle this would include

1. Multiple rate limiting strategies (sliding window, token bucket, fixed window) vs Throttle's single approach
2. More built-in identifier types (ip, user, route, api_key) with configurable headers
3. Cost-based rate limiting for different weight operations
4. Retry-After header support
5. More flexible configuration with callbacks for dynamic limits