<?php

declare(strict_types=1);

namespace App\Filament\Pages\Auth;

use Filament\Auth\Pages\PasswordReset\RequestPasswordReset as BaseRequestPasswordReset;
use Filament\Notifications\Notification;
use Illuminate\Support\Facades\Password;

/**
 * Overrides Filament's stock request-reset page to close an account
 * enumeration leak (SPEC 12.1 / ADM-01 "reset seguro"). The vendor page
 * shows a distinguishable danger notification for two statuses that only
 * ever occur for existing users, letting an attacker tell registered emails
 * apart from unregistered ones:
 *
 * - Password::INVALID_USER — no such user at all.
 * - Password::RESET_THROTTLED — Illuminate\Auth\Passwords\PasswordBroker
 *   only returns this when a token was already recently created for that
 *   user, which requires the user to exist. Two requests for the same
 *   registered email (allowed by this page's own rate limit of 2) would
 *   otherwise flip from "sent" to "throttled" while an unknown email stays
 *   "sent" both times — the same leak, reached a different way. The
 *   tradeoff: a legitimate user requesting twice sees "sent" again instead
 *   of "please wait", which is an acceptable UX cost on an admin-only panel.
 *
 * Existing-but-ineligible users (inactive, or since this panel now requires
 * a verified email) already resolve to Password::RESET_LINK_SENT with no
 * mail sent — see the vendor callback in the base class — so only these two
 * branches need normalizing here.
 */
class RequestPasswordReset extends BaseRequestPasswordReset
{
    protected function getFailureNotification(string $status): ?Notification
    {
        if (in_array($status, [Password::INVALID_USER, Password::RESET_THROTTLED], true)) {
            return $this->getSentNotification(Password::RESET_LINK_SENT);
        }

        return parent::getFailureNotification($status);
    }
}