seems to occur with 12.34: 419 page expired when logging in a different auth guard

[ghbob]

Laravel Version

12.34

PHP Version

8.4

Database Driver & Version

No response

Description

We work with auth guards quite a bit, so let's say "admin" and "user".
I am logged in as admin and then log in as user, the admin every quickly gets a 419 page expired.

First it's the browser dialog:

This page has expired. Would you like to refresh the page?

When I click the ok the Laravel error page shows: 419 page expired.
When I then refresh it's fine again, still logged in.

Rolled back to 12.33 where it doesn't occur so it seems to be a 12.34 change.

Only session related changelog entry was: #57204

@valorin any chance this could cause this?

Thanks!

Steps To Reproduce

[valorin]

Yeah, sounds like it is the cause. You're working across multiple tabs, right?

You'll need to update the CSRF token on every open page when you perform a login action.

[KasraMehr]

I've tested this behavior qith laravel 12.34.
It seems like the 419 error occurs when different auth guards (e.g user, admin, ...) are used in the same window and defferent tabs.
When you log in, Laravel creates a new session and CSRF token. This makes the old token to be invalid so when you want to use POST action in the last tab, it weill give 419 page expired.

This seems normal to me, not a bug. one way to handle this is to refresh or update the CSRF token in the other tab.

[ghbob]

yes, it's different guards on different tabs.
it's probably quite noticeable because I am on a page the does some Livewire polling which triggers the error.
On "normal" page navigation it might just work because the new session + csrf would be loaded then anyway?

So I'd need to hook into all Livewire calls and get the new cookie (or trigger a refresh) before they actually post to avoid the error.

[AhmedAlaa4611]

I think you should avoid logging in multiple times using different tabs. Instead, you can use separate browsers or an InPrivate window.

[ghbob]

Ok, so the login action now regenerates the session to avoid session fixation.
Makes perfect sense, good for security, and leads to this change of behaviour (in this edge case).

I guess one option for apps where it's necessary to work with different contexts / guards at the same time (while not wanting to explain to the customer why they need to use two browser) would be to work with subdomains?
e.g., admin.example.com and user.example.com would each get their own cookie for their session guard.

Thanks everyone.