Skip to content

v0.5.102

Choose a tag to compare

@jaspertey jaspertey released this 30 Oct 13:27
5dd1a50

Upgrading

  • Run kit:update plan|apply for session-ui (re-pinned sha256:16054cbc…e084 → sha256:19cdf4c2…a360): Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword, Auth/VerifyEmail and Auth/Invitation/Show take the auth-state fixes below. ResetPasswordViewModel gains status; a host that hand-copies types/kit.d.ts copies it again. A host overriding lang/vendor/kit/{locale}/ui.php can add form.throttled and form.throttled_retry.

Fixed

  • The guest auth pages keep a rate-limited submit in the card. A 429 from a limiter (Fortify's login limiter, the verification resend, a reset or reset-link request) opened Inertia's error modal over the page. Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword and Auth/VerifyEmail now refuse the modal for a 429 only (onHttpException returns false), clear the stale field errors and show an in-card alert (role="alert"): "Too many requests. Try again in N seconds." when the response carries Retry-After, else "Too many requests. Try again in a moment." The copy is in the kit's ui lang file (form.throttled, form.throttled_retry). Any other HTTP error still gets Inertia's modal; nothing the server allows or limits changes.
  • A failed sign-in, reset or confirmation clears the password and marks the field. Auth/Login, Auth/ResetPassword and Auth/ConfirmPassword reset their password fields on error, set aria-invalid on the fields with an error, and move focus to the first one (the email after bad credentials).
  • A bad or expired reset token is visible. Fortify reports it on email, a hidden field on Auth/ResetPassword, so nothing showed. It now shows as an in-card alert with a "Request a new link" link to /forgot-password.
  • The reset-password page's status comes from its view model. ResetPasswordViewModel takes status (the flashed session status), so the FormStatus added in v0.5.97 shows the server's status without the host supplying it.
  • The sign-in page focuses the email field on load, as Auth/ConfirmPassword already focuses the password.

Changed

  • The auth forms validate in the card, not in the browser. Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword and the sign-up form on Auth/Invitation/Show carry novalidate, so the server's field errors render in the card (an address like "nobody" gets the "valid email address" error) instead of the browser's own bubble. The fields keep type="email", required and autocomplete.

What's Changed

Full Changelog: v0.5.101...v0.5.102