"The page has expired due to inactivity. Please refresh and try again."

Same here, except clearing the browser cache, it works for me. But this issue occurs often, and I don't want to clear the browser cache all the time...

So I remembered that this issue started to happen after I run composer update yesterday, when the Laravel Framework was upgraded from 5.5.19 to 5.5.20. I just tried to downgrade to 5.5.19 and it seems the issue is solved now. Maybe it's an issue from the 5.5.20.

Try this in your htaccess

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresDefault A0
    ExpiresByType text/html A0
    # Set up caching on media files for 1 year
    <FilesMatch "\.(jpg|png|gif|js|css|ico|woff|woff2|eot|svg|ttf)$">
        ExpiresDefault A31536000
    </FilesMatch>
</IfModule>

OR try below middleware method

https://robinz.in/csrf-token-session-error-with-laravel-on-ie-edge/

@cawecoy: Thanks for the response. I'm running 5.5.19 so I'm guessing that's not the problem. But just to be sure, I upgraded to version 5.5.20 and it's still giving me the issue.

@RamjithAp -- Thanks for the response. I happen to be running on a Forge-provisioned box with Nginx, not Apache.

Also, I think the P3P header issue is specific to older IE browsers (https://peteris.rocks/blog/exotic-http-headers/#p3p). I'm using recent versions of Firefox and Chrome when I get the error.

Does the error happen consistently or randomly?

@Talinon -- I've never seen it before in development. Just noticed it yesterday in production, but it's consistent -- I'm not able to get around it at all.

Luckily it's a brand new app and there's no production data in the database yet, just some demo data. I'm thinking I may just tear it down and re-deploy. But I'm still interested in knowing what's causing it (or even how to debug it) in case it happens in the future.

@samtax01 Thanks for your reply. But the problem isn't with the html b/c the CSRF field is being generated properly.

I revisited this issue today to see if I could make any progress on debugging. I still haven't solved it-- but here's what I figured out so far for anyone who may be interested:

• The application is sending out a 419 response code and the view is at Illuminate\Foundation\Exceptions\views\419.blade.php. (It took me longer than I care to admit to figure this out.)
• I overrode the TokenMismatchException Error Handler to help debug the error. So it was definitely a TokenMismatchException.
• The csrf_field() helper is appropriately creating the hidden input field and populating with the token.

The issue: $request->input('_token') and $request->session()->token() are different and this difference is throwing the TokenMismatchException at Illuminate\Foundation\Http\Middleware\VerifyCsrfToken::tokensMatch().

However, I have no idea what could be causing this, since the csrf_field() helper is basically just using csrf_token() to request the token from the session. So it seems like they would have to match... but they don't.

Update: I found out the problem is due to a new session being created on every request. Here is the behavior on my Forge deployment:

1. Landing page (GET) -> session ID: A1b2C3d4..... (found in session file storage)
2. Login page (GET) -> session ID: F5g6H7i8..... (for some reason a new session was started here, but this doesn't happen on my local version- the session file is found in storage)
3. Login page (POST) -> session ID: J9K0L1m2..... (throws TokenMismatchException after entering correct credentials. For some reason it starts yet another new session, but this session isn't found in session file storage.)

Any ideas why it might be re-generating a new session between each request-- and only on the Forge-hosted version? Maybe the Forge server can write (but not read) from session storage. Although that would seem odd.

I'm wracking my brains. I'm sure I've seen this before and it was something to do with Session Cookie Domain

    /*
    |--------------------------------------------------------------------------
    | Session Cookie Domain
    |--------------------------------------------------------------------------
    |
    | Here you may change the domain of the cookie used to identify a session
    | in your application. This will determine which domains the cookie is
    | available to in your application. A sensible default has been set.
    |
    */

    'domain' => env('SESSION_DOMAIN', null),

but I can't remember what...

Have you tried caching your config since some report intermittent issues reading the env file

@Snapey That was it! For some reason I had set the default 'domain' value in config/session.php to 'myapp.dev', which I'm guessing the myapp.com version didn't like. I set this back to null and now I'm logging in just fine without the page expiration error. This explains why I wasn't getting the same issue on my local version. Thank you!!

Closing and opening a new tab woked for me

In case anyone else comes across this post while encountering the same problem, I did everything suggested here (also everything suggested here: https://stackoverflow.com/questions/45994235/laravel-5-5-login-and-register-page-saysthe-page-has-expired-due-to-inactivity) including using a new browser and nothing worked.

What finally worked was changing the session_driver to database in the .env file (and creating/running the migration for the sessions table).

Anyone else having problems with this? I got csr field token, I've tried changing the session driver to everything, also deleting the files on session folder... I'm dying in here. The website was working fine until one week ago. Sudenly I get this Page Expired error page. Session domain also null. Tried everything in the comments. I even re-uploaded the project to the host.

I did the same as @cawecoy mentioned. I've downgraded from 5.5.26 to 5.5.19 and it worked. It seems like it is a bug from version 5.5.20 onwards.

This is really weird. I have the same problem. I have tried everything. Clear commands and moving sessions to database, using memcached, downgrading laravel to 5.5.19 but nothing helps. Users still get random inactivity errors on login and logout pages... but not on any other page.

I have no idea whats going on. I do not know how to fix this.

So, i've worked a full day on this problem. I think all depends, in my case, by particular laravel situation where 2 application live on same domain but on multiple subdomain.

If is this the case, then, you need to change in your .env file the APP_NAME field, setting a proper value for every application (mostly different for every application).

In addition i've changed the APP_URL field setting as value http://127.0.0.1, this worked in my situation.

I think basically the problem is due to session that, probably, in Laravel architecture and with some browser (i had the problem with Chrome and Firefox, but not with Explorer and Safari) can be confused by some php class, then the data are accessed in a wrong way and csrf token results invalid.

I hope this can help someone ;)

I have the same problem only from Android phones default browser some of them, I tried to clear cache and reset all things and still have the same page "The page has expired " , and I tried many things without any luck .

I have the craziest fix to this

//errors/419.blade.php

@extends('errors::layout')

@section('title', 'Page Expired')

@section('message')
    The page has expired due to inactivity.
    <br/><br/>
    <a href="{{ url()->previous()  }}" style="text-decoration: none; color: inherit">Click Here To Refresh</a>
@stop

This is better please...

1 : create router for clear cache

Route::get('clear-cache', function () {
     Artisan::call('config:cache');
     Artisan::call('config:clear');
     Artisan::call('cache:clear');
    return "Cache is cleared";
});

2 : set SESSION_DOMAIN in .env file SESSION_DOMAIN=127.0.0.1 or SESSION_DOMAIN= 3:Delete all cookies stored in your Browser search. Because Laravel first goes to your old cookies to read your information when you login and use finish Now everything must work properly

@ichigoo better to cache routes and config in production.

Thanks for contributing to 2 year old question - and one that is already marked with an answer.

I have same error with laravel and livewire.

thanks for this post

if someone is still having this issue then I want you to check the server storage. In my case the server storage was the culprit because it did not allow any session to be stored on server session file because of storage full.

changing the session domain from 127.0.0.1 to localhost and vice versa fixes the issue for me.