Laravel Fortify
简介
Laravel Fortify 是 Laravel 的前端无关身份验证后端实现。 Fortify 注册了实现 Laravel 所有身份验证功能所需的路由和控制器,包括登录、注册、密码重置、电子邮件验证等。安装Fortify后,您可以运行route:list Artisan命令来查看Fortify已注册的路由。
由于 Fortify 不提供自己的用户界面,因此它需要与您自己的用户界面配对,该用户界面向其注册的路由发出请求。我们将在本文档的其余部分中详细讨论如何向这些路由发出请求。
INFO
请记住,Fortify 是一个旨在让您在实现 Laravel 身份验证功能方面领先一步的软件包。 您不需要使用它。 您始终可以按照 authentication、password reset 和 email verification 文档中提供的文档手动与 Laravel 的身份验证服务进行交互。
什么是 Fortify?
如前所述,Laravel Fortify 是 Laravel 的前端不可知身份验证后端实现。 Fortify 注册了实现 Laravel 所有身份验证功能所需的路由和控制器,包括登录、注册、密码重置、电子邮件验证等。
您无需使用 Fortify 即可使用 Laravel 的身份验证功能。 您始终可以按照 authentication、password reset 和 email verification 文档中提供的文档手动与 Laravel 的身份验证服务进行交互。
如果你是 Laravel 新手,在尝试使用 Laravel Fortify 之前,不妨先了解 Laravel Breeze 应用起步套件。Laravel Breeze 为应用提供包含 Tailwind CSS 构建界面的认证脚手架。与 Fortify 不同,Breeze 会将路由和控制器直接发布到你的应用中,方便你先熟悉 Laravel 的认证功能,再让 Laravel Fortify 为你实现这些功能。
Laravel Fortify 本质上是把 Laravel Breeze 的路由与控制器做成不包含用户界面的包。这样你仍可快速搭建应用认证层的后端实现,而无需绑定特定前端方案。
我什么时候应该使用 Fortify?
您可能想知道什么时候适合使用 Laravel Fortify。首先,如果您使用 Laravel 的 application starter kits 之一,则不需要安装 Laravel Fortify,因为所有 Laravel 的应用程序入门工具包都使用 Fortify 并且已经提供了完整的身份验证实现。
如果您没有使用应用程序入门工具包并且您的应用程序需要身份验证功能,您有两种选择:手动实现应用程序的身份验证功能或使用 Laravel Fortify 提供这些功能的后端实现。
如果您选择安装 Fortify,您的用户界面将向本文档中详细介绍的 Fortify 身份验证路由发出请求,以便对用户进行身份验证和注册。
如果您选择手动与 Laravel 的身份验证服务交互而不是使用 Fortify,则可以按照 authentication、password reset 和 email verification 文档中提供的文档进行操作。
Laravel Fortify 和 Laravel Sanctum
一些开发人员对 Laravel Sanctum 和 Laravel Fortify 之间的区别感到困惑。由于这两个包解决了两个不同但相关的问题,Laravel Fortify 和 Laravel Sanctum 并不是相互排斥或竞争的包。
Laravel Sanctum 只关心管理 API 令牌并使用会话 cookie 或令牌对现有用户进行身份验证。 Sanctum不提供任何处理用户注册、密码重置等的路由。
如果您尝试为提供 API 或作为单页应用程序后端的应用程序手动构建身份验证层,您完全有可能同时使用 Laravel Fortify(用于用户注册、密码重置等)和 Laravel Sanctum(API 令牌管理、会话身份验证)。
安装
首先,使用 Composer 包管理器安装 Fortify:
composer require laravel/fortify接下来,使用 fortify:install Artisan 命令发布 Fortify 的资源:
php artisan fortify:install此命令会将 Fortify 的操作发布到您的 app/Actions 目录,如果该目录不存在,则会创建该目录。此外,FortifyServiceProvider、配置文件和所有必要的数据库迁移都将被发布。
接下来,您应该迁移数据库:
php artisan migrateFortify 功能
fortify 配置文件包含一个 features 配置数组,用于定义 Fortify 默认暴露哪些后端路由 / 功能。若未与 Laravel Jetstream 一起使用 Fortify,建议仅启用下列功能——它们是大多数 Laravel 应用提供的基础认证功能:
'features' => [
Features::registration(),
Features::resetPasswords(),
Features::emailVerification(),
],禁用视图
默认情况下,Fortify 定义旨在返回视图的路由,例如登录屏幕或注册屏幕。但是,如果您正在构建 JavaScript 驱动的单页应用程序,则可能不需要这些路由。因此,您可以通过将应用程序的 config/fortify.php 配置文件中的 views 配置值设置为 false 来完全禁用这些路由:
'views' => false,禁用视图和密码重置
如果您选择禁用 Fortify 的视图并且将为您的应用程序实现密码重置功能,您仍然应该定义一个名为 password.reset 的路由,负责显示应用程序的「重置密码」视图。这是必要的,因为 Laravel 的 Illuminate\Auth\Notifications\ResetPassword 通知将通过 password.reset 命名路由生成密码重置 URL。
身份验证
首先,我们需要指示 Fortify 如何返回「登录」视图。请记住,Fortify 是一个无头身份验证库。如果您想要已为您完成的 Laravel 身份验证功能的前端实现,您应该使用 application starter kit。
所有身份验证视图的呈现逻辑都可以使用通过 Laravel\Fortify\Fortify 类提供的适当方法进行自定义。通常,您应该从应用程序的 App\Providers\FortifyServiceProvider 类的 boot 方法调用此方法。 Fortify 将负责定义返回此视图的 /login 路由:
use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::loginView(function () {
return view('auth.login');
});
// ...
}您的登录模板应包含一个向 /login 发出 POST 请求的表单。 /login端点需要一个字符串email / username和一个password。电子邮件/用户名字段的名称应与 config/fortify.php 配置文件中的 username 值匹配。此外,可以提供布尔值 remember 字段来指示用户想要使用 Laravel 提供的「记住我」功能。
如果登录尝试成功,Fortify 会将您重定向到通过应用程序的 fortify 配置文件中的 home 配置选项配置的 URI。如果登录请求是 XHR 请求,将返回 200 HTTP 响应。
如果请求不成功,用户将被重定向回登录屏幕,并且验证错误将通过共享的 $errors Blade template variable 提供给您。或者,对于 XHR 请求,验证错误将随 422 HTTP 响应一起返回。
自定义用户身份验证
Fortify 将根据提供的凭据和为您的应用程序配置的身份验证防护自动检索和验证用户。但是,您有时可能希望对登录凭据的身份验证方式和用户的检索方式进行完全自定义。值得庆幸的是,Fortify 允许您使用 Fortify::authenticateUsing 方法轻松完成此任务。
该方法接受一个接收传入 HTTP 请求的闭包。该闭包负责验证附加到请求的登录凭据并返回关联的用户实例。如果凭据无效或找不到用户,则闭包应返回null或false。通常,应该从 FortifyServiceProvider 的 boot 方法调用此方法:
use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::authenticateUsing(function (Request $request) {
$user = User::where('email', $request->email)->first();
if ($user &&
Hash::check($request->password, $user->password)) {
return $user;
}
});
// ...
}认证卫士
您可以在应用程序的 fortify 配置文件中自定义 Fortify 使用的身份验证防护。但是,您应该确保配置的防护是Illuminate\Contracts\Auth\StatefulGuard的实现。如果您尝试使用 Laravel Fortify 来验证 SPA,则应该将 Laravel 的默认 web 防护与 Laravel Sanctum 结合使用。
自定义身份验证管道
Laravel Fortify 通过可调用类的管道对登录请求进行身份验证。如果您愿意,您可以定义一个自定义的类管道,登录请求应通过该类进行管道传输。每个类都应该有一个 __invoke 方法,用于接收传入的 Illuminate\Http\Request 实例,并且与 middleware 一样,还有一个 $next 变量,调用该变量以便将请求传递给管道中的下一个类。
要定义自定义管道,您可以使用 Fortify::authenticateThrough 方法。此方法接受一个闭包,该闭包应返回类数组以通过管道传输登录请求。通常,应该从 App\Providers\FortifyServiceProvider 类的 boot 方法调用此方法。
下面的示例包含默认管道定义,您可以在进行自己的修改时将其用作起点:
use Laravel\Fortify\Actions\AttemptToAuthenticate;
use Laravel\Fortify\Actions\CanonicalizeUsername;
use Laravel\Fortify\Actions\EnsureLoginIsNotThrottled;
use Laravel\Fortify\Actions\PrepareAuthenticatedSession;
use Laravel\Fortify\Actions\RedirectIfTwoFactorAuthenticatable;
use Laravel\Fortify\Features;
use Laravel\Fortify\Fortify;
use Illuminate\Http\Request;
Fortify::authenticateThrough(function (Request $request) {
return array_filter([
config('fortify.limiters.login') ? null : EnsureLoginIsNotThrottled::class,
config('fortify.lowercase_usernames') ? CanonicalizeUsername::class : null,
Features::enabled(Features::twoFactorAuthentication()) ? RedirectIfTwoFactorAuthenticatable::class : null,
AttemptToAuthenticate::class,
PrepareAuthenticatedSession::class,
]);
});身份验证限制
默认情况下,Fortify 将使用 EnsureLoginIsNotThrottled 中间件限制身份验证尝试。该中间件会限制用户名和 IP 地址组合特有的尝试。
某些应用程序可能需要不同的方法来限制身份验证尝试,例如仅通过 IP 地址进行限制。因此,Fortify 允许您通过 fortify.limiters.login 配置选项指定自己的 rate limiter。当然,此配置选项位于应用程序的 config/fortify.php 配置文件中。
INFO
结合使用限制、two-factor authentication和外部 Web 应用程序防火墙 (WAF) 将为您的合法应用程序用户提供最强大的防御。
自定义重定向
如果登录尝试成功,Fortify 会将您重定向到通过应用程序的 fortify 配置文件中的 home 配置选项配置的 URI。如果登录请求是 XHR 请求,将返回 200 HTTP 响应。用户注销应用程序后,用户将被重定向到 / URI。
如果您需要对此行为进行高级自定义,您可以将 LoginResponse 和 LogoutResponse 合约的实现绑定到 Laravel service container 中。通常,这应该在应用程序的 App\Providers\FortifyServiceProvider 类的 register 方法中完成:
use Laravel\Fortify\Contracts\LogoutResponse;
/**
* Register any application services.
*/
public function register(): void
{
$this->app->instance(LogoutResponse::class, new class implements LogoutResponse {
public function toResponse($request)
{
return redirect('/');
}
});
}双因素认证
当启用 Fortify 的双因素身份验证功能时,用户需要在身份验证过程中输入六位数字令牌。此令牌是使用基于时间的一次性密码 (TOTP) 生成的,可以从任何 TOTP 兼容的移动身份验证应用程序(例如 Google Authenticator)检索该密码。
在开始之前,您应该首先确保应用程序的 App\Models\User 模型使用 Laravel\Fortify\TwoFactorAuthenticatable 特征:
<?php
namespace App\Models;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Fortify\TwoFactorAuthenticatable;
class User extends Authenticatable
{
use Notifiable, TwoFactorAuthenticatable;
}Next, you should build a screen within your application where users can manage their two factor authentication settings. This screen should allow the user to enable and disable two factor authentication, as well as regenerate their two factor authentication recovery codes.
By default, the
featuresarray of thefortifyconfiguration file instructs Fortify's two factor authentication settings to require password confirmation before modification. Therefore, your application should implement Fortify's password confirmation feature before continuing.
Enabling Two Factor Authentication
To begin enabling two factor authentication, your application should make a POST request to the /user/two-factor-authentication endpoint defined by Fortify. If the request is successful, the user will be redirected back to the previous URL and the status session variable will be set to two-factor-authentication-enabled. You may detect this status session variable within your templates to display the appropriate success message. If the request was an XHR request, 200 HTTP response will be returned.
After choosing to enable two factor authentication, the user must still "confirm" their two factor authentication configuration by providing a valid two factor authentication code. So, your "success" message should instruct the user that two factor authentication confirmation is still required:
```blade
@if (session('status') == 'two-factor-authentication-enabled')
<div class="mb-4 font-medium text-sm">
Please finish configuring two factor authentication below.
</div>
@endif
Next, you should display the two factor authentication QR code for the user to scan into their authenticator application. If you are using Blade to render your application's frontend, you may retrieve the QR code SVG using the `twoFactorQrCodeSvg` method available on the user instance:$request->user()->twoFactorQrCodeSvg();
If you are building a JavaScript powered frontend, you may make an XHR GET request to the `/user/two-factor-qr-code` endpoint to retrieve the user's two factor authentication QR code. This endpoint will return a JSON object containing an `svg` key.
#### Confirming Two Factor Authentication
In addition to displaying the user's two factor authentication QR code, you should provide a text input where the user can supply a valid authentication code to "confirm" their two factor authentication configuration. This code should be provided to the Laravel application via a POST request to the `/user/confirmed-two-factor-authentication` endpoint defined by Fortify.
If the request is successful, the user will be redirected back to the previous URL and the `status` session variable will be set to `two-factor-authentication-confirmed`:@if (session('status') == 'two-factor-authentication-confirmed')
<div class="mb-4 font-medium text-sm">
Two factor authentication confirmed and enabled successfully.
</div>
@endif
If the request to the two factor authentication confirmation endpoint was made via an XHR request, a `200` HTTP response will be returned.
#### Displaying the Recovery Codes
You should also display the user's two factor recovery codes. These recovery codes allow the user to authenticate if they lose access to their mobile device. If you are using Blade to render your application's frontend, you may access the recovery codes via the authenticated user instance:(array) $request->user()->recoveryCodes()
If you are building a JavaScript powered frontend, you may make an XHR GET request to the `/user/two-factor-recovery-codes` endpoint. This endpoint will return a JSON array containing the user's recovery codes.
To regenerate the user's recovery codes, your application should make a POST request to the `/user/two-factor-recovery-codes` endpoint.
### Authenticating With Two Factor Authentication
During the authentication process, Fortify will automatically redirect the user to your application's two factor authentication challenge screen. However, if your application is making an XHR login request, the JSON response returned after a successful authentication attempt will contain a JSON object that has a `two_factor` boolean property. You should inspect this value to know whether you should redirect to your application's two factor authentication challenge screen.
To begin implementing two factor authentication functionality, we need to instruct Fortify how to return our two factor authentication challenge view. All of Fortify's authentication view rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your application's `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::twoFactorChallengeView(function () {
return view('auth.two-factor-challenge');
});// ...
}
Fortify will take care of defining the `/two-factor-challenge` route that returns this view. Your `two-factor-challenge` template should include a form that makes a POST request to the `/two-factor-challenge` endpoint. The `/two-factor-challenge` action expects a `code` field that contains a valid TOTP token or a `recovery_code` field that contains one of the user's recovery codes.
If the login attempt is successful, Fortify will redirect the user to the URI configured via the `home` configuration option within your application's `fortify` configuration file. If the login request was an XHR request, a 204 HTTP response will be returned.
If the request was not successful, the user will be redirected back to the two factor challenge screen and the validation errors will be available to you via the shared `$errors` [Blade template variable](/11.x/validation#quick-displaying-the-validation-errors). Or, in the case of an XHR request, the validation errors will be returned with a 422 HTTP response.
### Disabling Two Factor Authentication
To disable two factor authentication, your application should make a DELETE request to the `/user/two-factor-authentication` endpoint. Remember, Fortify's two factor authentication endpoints require [password confirmation](#password-confirmation) prior to being called.
## Registration
To begin implementing our application's registration functionality, we need to instruct Fortify how to return our "register" view. Remember, Fortify is a headless authentication library. If you would like a frontend implementation of Laravel's authentication features that are already completed for you, you should use an [application starter kit](/11.x/starter-kits).
All of Fortify's view rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::registerView(function () {
return view('auth.register');
});// ...
}
Fortify will take care of defining the `/register` route that returns this view. Your `register` template should include a form that makes a POST request to the `/register` endpoint defined by Fortify.
The `/register` endpoint expects a string `name`, string email address / username, `password`, and `password_confirmation` fields. The name of the email / username field should match the `username` configuration value defined within your application's `fortify` configuration file.
If the registration attempt is successful, Fortify will redirect the user to the URI configured via the `home` configuration option within your application's `fortify` configuration file. If the request was an XHR request, a 201 HTTP response will be returned.
If the request was not successful, the user will be redirected back to the registration screen and the validation errors will be available to you via the shared `$errors` [Blade template variable](/11.x/validation#quick-displaying-the-validation-errors). Or, in the case of an XHR request, the validation errors will be returned with a 422 HTTP response.
### Customizing Registration
The user validation and creation process may be customized by modifying the `App\Actions\Fortify\CreateNewUser` action that was generated when you installed Laravel Fortify.
## Password Reset
### Requesting a Password Reset Link
To begin implementing our application's password reset functionality, we need to instruct Fortify how to return our "forgot password" view. Remember, Fortify is a headless authentication library. If you would like a frontend implementation of Laravel's authentication features that are already completed for you, you should use an [application starter kit](/11.x/starter-kits).
All of Fortify's view rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your application's `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::requestPasswordResetLinkView(function () {
return view('auth.forgot-password');
});// ...
}
Fortify will take care of defining the `/forgot-password` endpoint that returns this view. Your `forgot-password` template should include a form that makes a POST request to the `/forgot-password` endpoint.
The `/forgot-password` endpoint expects a string `email` field. The name of this field / database column should match the `email` configuration value within your application's `fortify` configuration file.
#### Handling the Password Reset Link Request Response
If the password reset link request was successful, Fortify will redirect the user back to the `/forgot-password` endpoint and send an email to the user with a secure link they can use to reset their password. If the request was an XHR request, a 200 HTTP response will be returned.
After being redirected back to the `/forgot-password` endpoint after a successful request, the `status` session variable may be used to display the status of the password reset link request attempt.
The value of the `$status` session variable will match one of the translation strings defined within your application's `passwords` [language file](/11.x/localization). If you would like to customize this value and have not published Laravel's language files, you may do so via the `lang:publish` Artisan command:@if (session('status'))
<div class="mb-4 font-medium text-sm text-green-600">
{{ session('status') }}
</div>
@endif
If the request was not successful, the user will be redirected back to the request password reset link screen and the validation errors will be available to you via the shared `$errors` [Blade template variable](/11.x/validation#quick-displaying-the-validation-errors). Or, in the case of an XHR request, the validation errors will be returned with a 422 HTTP response.
### Resetting the Password
To finish implementing our application's password reset functionality, we need to instruct Fortify how to return our "reset password" view.
All of Fortify's view rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your application's `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
use Illuminate\Http\Request;/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::resetPasswordView(function (Request $request) {
return view('auth.reset-password', ['request' => $request]);
});// ...
}
Fortify will take care of defining the route to display this view. Your `reset-password` template should include a form that makes a POST request to `/reset-password`.
The `/reset-password` endpoint expects a string `email` field, a `password` field, a `password_confirmation` field, and a hidden field named `token` that contains the value of `request()->route('token')`. The name of the "email" field / database column should match the `email` configuration value defined within your application's `fortify` configuration file.
#### Handling the Password Reset Response
If the password reset request was successful, Fortify will redirect back to the `/login` route so that the user can log in with their new password. In addition, a `status` session variable will be set so that you may display the successful status of the reset on your login screen:@if (session('status'))
<div class="mb-4 font-medium text-sm text-green-600">
{{ session('status') }}
</div>
@endif
If the request was an XHR request, a 200 HTTP response will be returned.
If the request was not successful, the user will be redirected back to the reset password screen and the validation errors will be available to you via the shared `$errors` [Blade template variable](/11.x/validation#quick-displaying-the-validation-errors). Or, in the case of an XHR request, the validation errors will be returned with a 422 HTTP response.
### Customizing Password Resets
The password reset process may be customized by modifying the `App\Actions\ResetUserPassword` action that was generated when you installed Laravel Fortify.
## Email Verification
After registration, you may wish for users to verify their email address before they continue accessing your application. To get started, ensure the `emailVerification` feature is enabled in your `fortify` configuration file's `features` array. Next, you should ensure that your `App\Models\User` class implements the `Illuminate\Contracts\Auth\MustVerifyEmail` interface.
Once these two setup steps have been completed, newly registered users will receive an email prompting them to verify their email address ownership. However, we need to inform Fortify how to display the email verification screen which informs the user that they need to go click the verification link in the email.
All of Fortify's view's rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your application's `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::verifyEmailView(function () {
return view('auth.verify-email');
});// ...
}
Fortify will take care of defining the route that displays this view when a user is redirected to the `/email/verify` endpoint by Laravel's built-in `verified` middleware.
Your `verify-email` template should include an informational message instructing the user to click the email verification link that was sent to their email address.
#### Resending Email Verification Links
If you wish, you may add a button to your application's `verify-email` template that triggers a POST request to the `/email/verification-notification` endpoint. When this endpoint receives a request, a new verification email link will be emailed to the user, allowing the user to get a new verification link if the previous one was accidentally deleted or lost.
If the request to resend the verification link email was successful, Fortify will redirect the user back to the `/email/verify` endpoint with a `status` session variable, allowing you to display an informational message to the user informing them the operation was successful. If the request was an XHR request, a 202 HTTP response will be returned:@if (session('status') == 'verification-link-sent')
<div class="mb-4 font-medium text-sm text-green-600">
A new email verification link has been emailed to you!
</div>
@endif
### Protecting Routes
To specify that a route or group of routes requires that the user has verified their email address, you should attach Laravel's built-in `verified` middleware to the route. The `verified` middleware alias is automatically registered by Laravel and serves as an alias for the `Illuminate\Auth\Middleware\EnsureEmailIsVerified` middleware:Route::get('/dashboard', function () {
// ...
})->middleware(['verified']);
## Password Confirmation
While building your application, you may occasionally have actions that should require the user to confirm their password before the action is performed. Typically, these routes are protected by Laravel's built-in `password.confirm` middleware.
To begin implementing password confirmation functionality, we need to instruct Fortify how to return our application's "password confirmation" view. Remember, Fortify is a headless authentication library. If you would like a frontend implementation of Laravel's authentication features that are already completed for you, you should use an [application starter kit](/11.x/starter-kits).
All of Fortify's view rendering logic may be customized using the appropriate methods available via the `Laravel\Fortify\Fortify` class. Typically, you should call this method from the `boot` method of your application's `App\Providers\FortifyServiceProvider` class:use Laravel\Fortify\Fortify;
/**
* Bootstrap any application services.
*/
public function boot(): void
{
Fortify::confirmPasswordView(function () {
return view('auth.confirm-password');
});// ...
}
Fortify will take care of defining the `/user/confirm-password` endpoint that returns this view. Your `confirm-password` template should include a form that makes a POST request to the `/user/confirm-password` endpoint. The `/user/confirm-password` endpoint expects a `password` field that contains the user's current password.
If the password matches the user's current password, Fortify will redirect the user to the route they were attempting to access. If the request was an XHR request, a 201 HTTP response will be returned.
If the request was not successful, the user will be redirected back to the confirm password screen and the validation errors will be available to you via the shared `$errors` Blade template variable. Or, in the case of an XHR request, the validation errors will be returned with a 422 HTTP response.