当使用 Laravel Fortify 构建认证系统时，如果遇到登录请求成功重定向但用户实际未认证的问题，这通常是由于缺少会话启动中间件所致。本文将详细阐述此问题的根源，并提供通过在 `app/Http/Kernel.php` 中添加 `IlluminateSessionMiddlewareStartSession::class` 中间件来解决该问题的专业指南。
Laravel Fortify 认证流程与常见问题
Laravel Fortify 提供了一套快速构建认证后端服务的解决方案，它处理了注册、登录、密码重置等核心功能。当将其与一个独立的 JavaScript 前端（如 React）结合使用时，通常会通过 HTTP 请求与 Fortify 提供的 API 端点进行交互。
一个常见的场景是，当用户提交登录表单到 /auth/login 端点后，Fortify 会正确处理凭据并发出重定向响应（例如到 / 路径），这在网络请求层面看起来是成功的。然而，当尝试通过 Auth::check() 方法检查用户认证状态时，却始终返回 false，表明用户并未真正登录。即使是用户注册成功，数据库中新增了记录并重定向，也面临同样的问题：新注册的用户并未自动登录。
这种现象通常意味着认证过程的最后一步——将用户登录状态持久化到会话中——未能成功执行。
问题根源：会话中间件缺失
Laravel 的认证机制高度依赖于 PHP 会话来存储和管理用户的登录状态。当用户成功通过认证后，Laravel 会将会话 ID 与用户的认证信息关联起来，并在后续请求中通过会话 ID 恢复用户的认证状态。
如果 IlluminateSessionMiddlewareStartSession::class 这个关键的会话中间件未被正确加载或执行，那么：
Laravel 将无法为传入的请求启动或恢复一个会话。即使 Fortify 内部逻辑成功验证了用户凭据，也无法将用户的认证信息写入到一个有效的会话中。因此，在请求结束后，用户的登录状态无法被持久化，导致后续请求中 Auth::check() 始终返回 false。
在 Laravel 应用中，StartSession 中间件通常包含在 web 中间件组中，该中间件组默认应用于所有 Web 路由。然而，在某些自定义配置或重构 app/Http/Kernel.php 时，这个中间件可能会被无意中移除或遗漏。
解决方案：添加 StartSession 中间件
解决此问题的核心在于确保每个请求都能正确启动或恢复会话。这可以通过在 app/Http/Kernel.php 文件的 $middleware 属性中全局添加 IlluminateSessionMiddlewareStartSession::class 中间件来实现。
请打开 app/Http/Kernel.php 文件，并修改 $middleware 数组，确保其中包含 IlluminateSessionMiddlewareStartSession::class：
[ AppHttpMiddlewareEncryptCookies::class, IlluminateCookieMiddlewareAddQueuedCookiesToResponse::class, // IlluminateSessionMiddlewareStartSession::class, // 如果已经全局添加，这里可以省略或检查 IlluminateViewMiddlewareShareErrorsFromSession::class, AppHttpMiddlewareVerifyCsrfToken::class, IlluminateRoutingMiddlewareSubstituteBindings::class, ], 'api' => [ // LaravelSanctumHttpMiddlewareEnsureFrontendRequestsAreStateful::class, 'throttle:api', IlluminateRoutingMiddlewareSubstituteBindings::class, ], ]; /** * The application's route middleware. * * These middleware may be assigned to groups or individual routes. * * @var array */ protected $routeMiddleware = [ 'auth' => AppHttpMiddlewareAuthenticate::class, 'auth.basic' => IlluminateAuthMiddlewareAuthenticateWithBasicAuth::class, 'bindings' => IlluminateRoutingMiddlewareSubstituteBindings::class, 'cache.headers' => IlluminateHttpMiddlewareSetCacheHeaders::class, 'can' => IlluminateAuthMiddlewareAuthorize::class, 'guest' => AppHttpMiddlewareRedirectIfAuthenticated::class, 'signed' => IlluminateRoutingMiddlewareValidateSignature::class, 'throttle' => IlluminateRoutingMiddlewareThrottleRequests::class, 'verified' => IlluminateAuthMiddlewareEnsureEmailIsVerified::class, ];}
注意事项：
位置选择: 将 StartSession 放在全局 $middleware 数组中是确保所有请求都能处理会话的最直接方法。如果它已经存在于 web 中间件组中，并且你的 Fortify 路由使用了 web 中间件组（Fortify 的 fortify.php 配置文件中 middleware 键默认设置为 [‘web’]），那么理论上应该有效。但如果全局缺失，或者 web 组被修改，则需要手动添加。CORS 与 Session: 如果你的前端与后端部署在不同域名，并且涉及到跨域请求，请确保 HandleCors 中间件（如 FruitcakeCorsHandleCors::class 或 Laravel 内置的 IlluminateHttpMiddlewareHandleCors::class）在 StartSession 之前被执行。这样可以确保 CORS 头部在会话启动前被正确处理，防止潜在的会话 Cookie 问题。web 中间件组: 检查 app/Http/Kernel.php 中的 web 中间件组，它通常包含 StartSession。如果你没有全局添加，而是依赖 web 组，请确保 web 组中包含 IlluminateSessionMiddlewareStartSession::class。
验证解决方案
完成上述修改后，重新测试你的认证流程：
尝试通过 React 前端发送登录请求。检查浏览器开发者工具中的网络请求，确认登录请求成功并重定向。在你的 API 控制器中（例如 checkIfLoggedIn 方法），再次调用 Auth::check()。此时应该返回 true，表明用户已成功登录。
// APIController.phppublic function checkIfLoggedIn(){ if (Auth::check()) { return response()->json(['message' => 'Logged in', 'user' => Auth::user()]); // 可以返回用户信息 } return response()->json(['message' => 'Not logged in']);}
通过以上步骤，你将能够解决 Laravel Fortify 登录后用户未认证的问题，确保会话管理正常工作，从而正确地持久化用户登录状态。
以上就是解决 Laravel Fortify 登录后会话未启动问题的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1331222.html
微信扫一扫 
支付宝扫一扫 
