adversarial code review

I have audited the password reset implementation across four adversarial passes. ## Adversarial Review Report | Pass | Result | Findings | | :--- | :--- | :--- | | **1. Verifier** | PASS | Happy path verified: `User.find_by(email:)` correctly triggers the `TokenService`. Manual trace confirms the token is stored in the `reset_tokens` table before the mailer is invoked. | | **2. Skeptic** | FAIL | **Blocking:** The diff includes an unrelated change to the `User#login` method (extra logging) which is scope creep. **Blocking:** No unit tests were added for the `TokenService` expiration logic. | | **3. Edge-case** | PASS | Handled empty email string (returns 200 to prevent enumeration). Traced rapid repeat requests; the existing `before_action` handles basic record locking. | | **4. Safety Gate** | FAIL | **Auth:** Pass. **Data:** Pass (parameterized query). **Exposure:** FAIL. The API response returns the full `User` object on success, exposing the `password_digest` hash. **Rate:** FAIL. No rate limiting on the external mailer call; vulnerable to cost-exhaustion. | ### Detailed Blocking Issues - **Information Leak:** The `PasswordResetsController#create` returns `render json: @user`, which includes sensitive fields. It must be scoped to `email` only. - **Resource Exhaustion:** There is no cooldown between reset requests. An attacker could trigger thousands of emails to a single address, incurring costs and potential IP blacklisting. - **Scope Creep:** Revert changes to `app/models/user.rb:42` regarding login logging; it belongs in a separate PR. **DO NOT SHIP YET** **Next steps** - Update the controller to return a generic success message instead of the User object. - Implement a 60-second cooldown per email/IP in the `PasswordResetsController`. - Add tests covering token expiration and malformed email inputs.