I stumbled upon the same problem today and did some debugging. When registering the /login route, Fortify applies the Illuminate\Routing\Middleware\ThrottleRequests:login middleware to it. This means, for every request to that route, the ThrottleRequests middleware will call the RateLimiter instance for that specified key. Apparently, Fortify doesn’t register a RateLimiter for the login key.
Due to the missing key in the $limiters property of the RateLimiter instance, the ThrottleRequests middleware uses its default fallback, which doesn’t handle the edge case “there SHOULD be a rate limiter for that key, but there isn’t.” really well. The $maxAttempts variable is set to 0 and will result in flaky rate limiting behaviour.
I feel like this is a bug in Fortify, because rate limiting is also happening in the \Laravel\Fortify\Actions\EnsureLoginIsNotThrottled action, which is invoked in the \Laravel\Fortify\Http\Controllers\AuthenticatedSessionController controller. I didn’t check this on a fresh Laravel installation, though, so I don’t want to jump to conclusions here.
Anyway, long story short: As a workaround, you can simply register a rate limiter for the “login” key in some of your providers, e. g. AppServiceProvider or AuthServiceProvider:
public function boot()
{
RateLimiter::for("login", function () {
Limit::perMinute(5);
});
}
Edit: I just realized that the rate limiter for the “login” key is indeed provided by Fortify within the FortifyServiceProvider class. If you happen to have a problem similar to the one discussed above, make sure that you added the FortifyServiceProvider class to your providers array in the config/app.php.
source : stackoverflow
