auth()方法在异常上为null [英] auth() method null on Exceptions

问题描述

我正在使用Laravel 5.4.23，当我在404页面上打auth()，auth()->check()，auth()->user()时遇到了这种情况，并且这些未初始化，因此在视图或任何地方返回null在那附近.

I was playing around with Laravel 5.4.23 and i came across this scenario when i hit a 404 page the auth(), auth()->check(), auth()->user(), and those are not initialized thus returning null in views, or anywhere near that.

我什至去AppServiceProvider.php类进行一些测试，

i even went to AppServiceProvider.php class to do some tests,

dd(auth()->check());

即使我已经登录，也会在boot方法中返回Null，这对我来说意义为0.

returns Null in the boot method, even if i'm logged in, which makes 0 sense to me.

这意味着，每当用户点击404页面时，导航栏等都不会呈现用户数据，例如，传统上，我们在导航栏中的右上角有用户配置文件按钮，就像在stackoverflow上一样，在这种情况下， Laravel，根据我所见，这是不可能的.

that means, whenever a users hits a 404 page, navbars and so on will not render the user data like for instance, traditionally we have the user profile button on top right side in navbar like here on stackoverflow, in that case in Laravel, this is not possible with what i'm seeing.

我是在正确的轨道上还是我错过了什么?

Am i on the right track or am i missing something ?

在我看来，Laravel在完成我测试的请求后尝试登录用户.

it appears to me that Laravel attempts to log the user in after completing the requests i tests.

希望我在这里找到答案.

hope i find the answer here.

谢谢.

更新:

在App \ Providers \ AppServiceProvider的boot方法中包括手动登录尝试似乎可以解决aut()命令中的null问题，但是我相信这将尝试在每个页面请求中两次登录用户，因为显然，Laravel在引导，异常请求和其他任何东西之后都无法登录.

including a manual login attempt in the boot method in App\Providers\AppServiceProvider seemed to fix the null issue in the aut() commands, but i believe this will attempt to log the user in twice per page request, since obviously Laravel is getting the logged in user after the boot, exceptions requests and dunno what else.

推荐答案

之所以会发生这种情况，是因为会话是由web中间件组初始化的.当找不到路由时，中间件将永远不会初始化.因此，应用程序无法从会话中找到经过身份验证的用户.

This happens because the session gets initialised by the web middleware group. When a route is not found the middleware never gets initialised. Therefore the application fails to find the authenticated user from the session.

但是有一个解决方法.将会话和cookie中间件从web中间件组移动到全局中间件似乎可以解决此问题.但是不利的是，应用程序中的每条路由都默认启用了会话和cookie.如果您有api路由，这可能会出现问题.

There's a workaround for this though. Moving the session and cookie middleware from the web middleware group to the global middleware seems to fix this. But the downside is that every single route in your application with have sessions and cookies enabled by default. This can be problematic if you have api routes.

移动(请勿复制)这些从web中间件组($middlewareGroups)到全局中间件列表($middleware)的路由.

MOVE (don't copy) these routes from web middleware group ($middlewareGroups) to the global middleware list ($middleware).

\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Session\Middleware\StartSession::class,

如果您不想在错误页面上使用他们的Remember_token检测用户，则可以跳过EncryptCookies中间件.

You can skip the EncryptCookies middleware if you don't want to detect users using their remember_token in your error pages.

这篇关于auth()方法在异常上为null的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！