Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

CreamyT's avatar

User is re-authed after failed Eloquent query

Spent some time tracking this down, and still quite confused. Short of it is, when a user logs in, a card on the dashboard makes an AJAX request to get a list of Purchase Orders. For troubleshooting this issue, I made it timeout after 30 seconds. It logs "Starting PO Query" when it starts, and in the try/catch it logs "Ending PO Query". IF the user logs out before that query finishes by click on the logout button, it will kick them to the login screen. They are clearly not logged in - can't hit protected routes, and a debug route spits out null for Auth::user().

However, as soon as the Eloquent query times out (I can tell by the Log update), the user is immediately logged back in. The page doesn't update on its own. However, I can access all protected routes, and if I go to a /login route I am redirected to the default-logged-in route of the dashboard. IF I wait to log out after the query fails/finishes, I am not automatically re-authed.

This project is Laravel 6.20.19. Login logic was originally built from the auth scaffolding, but is modified. I have setup logs for ALL routes being hit, and can confirm no route is being hit from the browser when the re-auth happens.

I pared down the logic and distilled it as best I could. The AJAX request hits a route, the route says get POs by and then returns it to a view with that data:

// CONTROLLER METHOD FROM ROUTE

public function recentPurchaseOrderList()
{
        $purchaseOrders = PurchaseOrder::openForClient();

        return view('dashboard.cards.open-purchase-orders')->with('purchaseOrders', $purchaseOrders);
}
// MODEL METHOD

public static function openForClient()
{
        $user = Auth::user();

        Log::debug('Accessing recent POs for ' . $user->email);

        try {
            $purchaseOrders = PurchaseOrder::where('clientId', '=', $user->client_id)
                                           ->where('status', '=', self::STATUS_SENT_TO_CUSTOMER)
                                           ->get();
        } catch (\Exception $e) {
            Log::debug('Failed to access recent POs for ' . $user->email);

            return [];
        }

        return $purchaseOrders;
}

The logout function is basic, and maybe it's something stupid I'm missing here?

public function logout(Request $request)
{
        User = Auth::user();
        Log::info('User logged out: ' . $user->email);

        $request->session()->flush();

        Auth::logout();

        return redirect('/login');
}

I'm just...at a loss. It seems like it's refreshing the session? I don't know what else to look at. The session config is pretty straightforward, but I can post that if it will be hopeful. Or if there is a config option I should look at. Thanks for any help anyone's able to offer!

0 likes
2 replies
Snapey's avatar
Snapey
Best Answer
Level 122

Q1. Why does your request take more than a few hundred milliseconds?

Q2. The session is clearly being reinstated by the response from the server. You could better logout with;

        Auth::logout();

        $request->session()->invalidate();

        $request->session()->regenerateToken();
1 like
CreamyT's avatar

Awesome, that did it. Thank you so much!

I figured it was something with the session, but I didn't know what else I should be doing besides flushing it. I did not see the invalidate() method on Laravel docs. It's listed in 8.x, although not in 6.x, which is what I was looking at since that's the version this project is on. I saw regenerate(), but the small paragraph suggested, from what I could read, on using it during login, not logout. I admittedly am not particularly knowledgeable on this aspect.

Regarding the time, it generally doesn't, which is why I never noticed this. The DB for this particular call is on another server, though in production it's quite fast. In fact, the only reason I did notice it was because of my local setup where a new VPN config was unable to reach this server, resulting in a timeout. And of course, I noticed this while I was refactoring login logic.

I went down a GIANT rabbit hole of figuring out how the heck I broke it with the login changes I made, when in fact I was discovering a old bug. So that didn't help!

Please or to participate in this conversation.