Framework: 419 Error when logged in with multi auth if remember me is checked

[HasanAlyazidi]

• Laravel Version: 5.5.19
• PHP Version: 7.1.7
• Database Driver & Version: MySQL 5.7.19

Description:

I have the following guards

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],

    'admin' => [
        'driver' => 'session',
        'provider' => 'admins',
    ],

    'api' => [
        'driver' => 'passport',
        'provider' => 'users',
    ],
],

web for end-users
admin for website administrators

each has his own auth and login/register pages and routes.

The issue is i get 419 error when i submit POSTs after i am logged in with the same email as a user (remember me is checked), and as an admin (remember me is checked too)

Steps To Reproduce:

• Log in using web auth with remember me is checked
• Log in again using admin auth with remember me is checked
• Submit any form with POST method

[laurencei]

I kind of feel this is expected.

If you have two different sessions - then how can Laravel know which CSRF token to send?

[HasanAlyazidi]

You are right, but it can be solved maybe by verifying and differentiating CSRF tokens according to the routes/guards/middlewares.

[laurencei]

How would that even work though? If you have Session A and Session B, which is the "right" one?

The fact is two different simulatnous sessions is not a supported function. You should have the one session, and enable different modes within it perhaps.

Or have users "switch" between modes.

But you cant have both simulatenously.

[HasanAlyazidi]

I think it should be one session for both if "PHP does not support multiple sessions". Anyway, how about setting different key prefix for each guard's session?

Example:

    'guards' => [
        'web' => [
            'driver' => 'session',
            'driver_prefix' => 'user_',
            'provider' => 'users',
        ],

        'admin' => [
            'driver' => 'session',
            'driver_prefix' => 'admin_',
            'provider' => 'admins',
        ],
    ],

'driver_prefix' may be replaced with 'provider', so web guard session is named 'users_session' and 'admins_session' for admin guard.

I think it can be solved anyway.

Thanks @laurencei

[bhulsman]

Having the same issue. Are there any workarounds or fixes you guys came up with in the end?

[HasanAlyazidi]

Nothing new @bhulsman

[laurencei]

As this is a suggestion, I will be closing your ticket here. You are able to open a ticket at https://github.com/laravel/ideas

Alternatively you are able to open a PR using the Contributions guidelines: https://laravel.com/docs/5.7/contributions#which-branch

If you feel I've closed this issue in error, please provide more information about how this is a framework issue, and I'll reopen the ticket.

Thanks in advance.

[Arduino1987]

Same issue. Need to work simultaneously as admin(admin guard) on /admin/* and on front-end (web guard), without SCRF token conflict

[KeitelDOG]

@Arduino1987 You might need to setup cookie => ... in session config with combined values to be unique for your admin and web, The browser behavior seems to create conflict with cookies with the same name, and the incorrect one seems to be passed to the request. I don't really know how browsers handle cookies but I know they can have conflicts with them on requests.
You can see my comment https://github.com/laravel/framework/issues/26106#issuecomment-444723768 from another issue that is similar.

[sharifzadesina]

@KeitelDOG Why at the first place we should have multiple sessions? we must have one session through whole app.

[KeitelDOG]

@sharifzadesina Browser doesn't know session, but cookie. And one laravel session is sent as one cookie value with a name to the browser, for example laravel_session=eyJpdiI6IisrbDY2Q3gwS2RZMnJRVE5WMGh....

One session is just an approach, 2 sessions through an App is not impossible though, I see developers asking for that and using it. I never use it, but by setting up another cookie that will be a 2nd session name, then Laravel will fetch the session name in cookie that is appropriate to User type, like laravel_member_session or laravel_admin_session.

But the problem is to know when to use member or admin session, because the member hasn't been authenticated yet. And to go from here :

'cookie' => env(
        'SESSION_COOKIE',
        str_slug(env('APP_NAME', 'Laravel'), '_').'_session'
    ),

to here :

'cookie' => env(
        'SESSION_COOKIE',
        str_slug(env('APP_NAME', 'Laravel'), '_').'_'.{{USER_TYPE}}.'_session'
    ),

Where User Type could come from the 1st Route part, like /admin/stats could bring admin type, and other URI could bring member type. Or if there was a way to tell Laravel to use a session name dynamically. And member will never trick a call to /admin/stats because Laravel won't find any match for laravel_admin_session for him.

[bhulsman]

@KeitelDOG Why at the first place we should have multiple sessions? we must have one session through whole app.

But how would you work with multiple user types? Like User and Admin for example?

[Arduino1987]

@KeitelDOG Thank you! I think it is good idea with multiple sessions (session cookies). I will try it. At now I have solved the problem with some overwriting for login/logout methods (I prevent session regeneration if user already logged in as admin/user role). But think it is will be easier to make separate StartSession middleware for admin-site area.

[sharifzadesina]

For me the problem were cause of laravel-debugbar, this packages were caused to session regeneration on every request.
I have multiple user types and I only have 1 session cookie, everything works as expected.

[bhulsman]

For me the problem were cause of laravel-debugbar, this packages were caused to session regeneration on every request.
I have multiple user types and I only have 1 session cookie, everything works as expected.

But that would only happen on the local/develop environment, not production, right?

[sharifzadesina]

@bhulsman the debugbar is disable in production, so yes it only happens of development.
but I think it is time to get rid of this old buggy package.

[aristotele]

@bhulsman the debugbar is disable in production, so yes it only happens of development.
but I think it is time to get rid of this old buggy package.

@sharifzadesina Thanks for save me, you're damn right

[quangthan155]

@HasanAlyazidi : could you tell me how did you fix it? I really need to know. Thank you somuch

[quangthan155]

@HasanAlyazidi do i need to uninstall laravel-debugbar packed on product or just disabled it?

[HasanAlyazidi]

Hi @quangthan155, you may ask @sharifzadesina since he believes laravel-debugbar is the culprit.