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

dangelsaurus's avatar

TokenMismatchException in Chrome L5

I recently added a new package "Intervention\Image" which required me to change my php.ini and restart apache as well as run composer to install the package..

Immediately after doing so, I'm now getting a TokenMismatchException error on a VERY simple form. It was doing it in both FF and Chrome until I cleared cache\cookies on both browsers and restarted the computer, and now it's only acting up with Chrome...

        {!! Form::open(array('url'=>'submitphoto', 'files'=>'true', 'class'=>'')) !!}

        <div class="form-group">
            {!! Form::label('title','Gallery Title',['class'=>''])!!}
            {!! Form::text('title',null,['class'=>'form-control'])!!}
        </div>
        <div class="form-group">
            {!! Form::label('description','Gallery Description',['class'=>''])!!}
            {!! Form::text('description',null,['class'=>'form-control'])!!}
        </div>

        {!!Form::submit('Create Photo Set',['id'=>'form-submit-button','class'=>'btn btn-primary form-control'])!!}
        {!! Form::close() !!}

The token is showing to have been submitted..

------WebKitFormBoundaryhlAqIvMGp5aBkE3b
Content-Disposition: form-data; name="_token"

Um1aQAKjpxE5l5GKGk02PweZUFk1o35wrnXMuGTf

What do I do next to troubleshoot this?

Here is the rest of the debug...

in VerifyCsrfToken.php line 46
at VerifyCsrfToken->handle(object(Request), object(Closure)) in VerifyCsrfToken.php line 17
at VerifyCsrfToken->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request)) in ShareErrorsFromSession.php line 55
at ShareErrorsFromSession->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request)) in StartSession.php line 61
at StartSession->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request)) in AddQueuedCookiesToResponse.php line 36
at AddQueuedCookiesToResponse->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request)) in EncryptCookies.php line 40
at EncryptCookies->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request)) in CheckForMaintenanceMode.php line 42
at CheckForMaintenanceMode->handle(object(Request), object(Closure)) in Pipeline.php line 125
at Pipeline->Illuminate\Pipeline\{closure}(object(Request))
at call_user_func(object(Closure), object(Request)) in Pipeline.php line 101
at Pipeline->then(object(Closure)) in Kernel.php line 115
at Kernel->sendRequestThroughRouter(object(Request)) in Kernel.php line 84
at Kernel->handle(object(Request)) in index.php line 53
0 likes
12 replies
BENderIsGr8te's avatar

The complexity of the form shouldn't make a difference, either the token is set or it's not. If it's strictly Chrome that is currently giving you this error I would delete all your cookies for your dev site that Chrome has stored.

Delete Cookies Method 1

Open Chrome Developer Tools -> Select the Resources Tab -> Select the Cookies Option -> Select the domain name and then delete the _token and any other cookies.

Delete Cookies Method 2

Settings -> Show Advanced Settings -> Content Settings -> All Cookies and Site Data

Then do a search for whatever your site is (dev.app or whatever). Then delete all the cookies.

At that point, if the problem persists then it may not be a Chrome issue.

dangelsaurus's avatar

I've deleted all cookies, there wasn't any change. I ended up going to another form from another controller and that submitted correctly, and then I went back to the form having problems, and it started working.

I've read quite a few post with others having issues with Tokenmismatchexception errors with L5 and it seems these issues have been encountered before. I'm lost, but at least it's working for the moment...

BENderIsGr8te's avatar

One big change between L4 and L5 is that L5 passes all POST requests through a CSRF middleware. The thinking that was you would always want to insure that every request was protected. The problem that was encountered (aside from random issues like you are encountering) is that it caused major headaches for RESTful applications. If I created an API with my app, people trying to PUT would need to send the token...which they did not have...so that was a huge fail which was discovered relatively quickly.

The work around was to disable all CSRF protection completely or to edit your middleware to not perform it on certain routes. L5.1 fixes this by allowing you to provided exceptions to CSRF in your routes.

Now, not much of that is directly related to your issue, just some background so you know that CSRF changed a lot in L5.

I wouldn't be surprised if Laravel's Session was causing you issues as well in that it was storing some random string on the server in its cache, and when you went to a new form the cache was essentially cleared.

At any rate, at least it's working (as you say...for the moment...)

dangelsaurus's avatar

Appreciate that info\insight. Is there a way to manually reset\clear the cache if this happens again?

BENderIsGr8te's avatar

That's a good question. I see artisan has the following command

php artisan cache:clear

I am not sure if that clears all the application cache or just that stored in a table. I just ran it on my production server (where I am using file for my sessions and got a success message saying Application cache cleared!. Maybe give that a go.

dangelsaurus's avatar

well this is fun... I'm getting the same error in all browsers the first time I start up for the day...The only fix is to go to another form on another page and somehow it "resets" things. The cache clear did nothing. What else could be causing this?

jekinney's avatar

I get the issue once in awhile and only chrome. Like most browsers when you close it, it doesn't shut down the program. When I run into the issue I make sure to shut chrome down and restart. I have also lesson the issues by turning reloading off which helps a lot by actually clearing any session data and temp cookies that chrome will store from a previous session before an error.

dangelsaurus's avatar

Unfortunately this is across the board in all browsers now

dangelsaurus's avatar

Just an FYI on this (after a year with working with Laravel) I do believe my problem was actually being caused by DebugBar. The page would load with a valid token, and then something DebugBar did would request a new token to be generated, so when I submitted my page, it would be expired. I know to expect this now as almost standard behavior with DebugBar...

https://github.com/barryvdh/laravel-debugbar/issues/310

Please or to participate in this conversation.