I've had a new laravel install since 5 days ago, Oct 18th 2016, and it's been working perfectly. No issues, been building my app as needed. Everything working fine. Now, I've not added in any additions to the auth system, I ran php artisan make:auth and that was it, I was using the vanilla auth system as is because that's all I needed. Here are my routes:
Auth::routes();
Route::resource('/posts', 'PostController');
Route::get('/admin', 'HomeController@getAdmin');
Route::get('/', 'HomeController@index');
Route::get('/blog', 'BlogController@getIndex');
Route::get('/blog/{slug}', ['as' => 'blog.single', 'uses' => 'BlogController@getSingle'])->where('slug', '[\w\d-_]+');
Here is the top of my views/auth/login.blade.php:
Everytime this is reported it ends up with a misconfiguration, and it's really hard to debug from where everything is working fine so I suggest that you install a fresh 5.3 instance, run php artisan make:auth
and then try the login/register form.
@themsaid hey, thanks for your reply. I did install a fresh instance of 5.3 but what if I ship this out to my client, and suddenly they aren't able to login?
So it works on a fresh installation?
ping @astr0naugh7
@themsaid I've been testing on a new install and I copied over all my files and it's working. So with no changes, why suddenly would it be working now? And when I take it to production and the client gets this error, what then?
Well I have many apps running on laravel and never had this problem :) It's really a matter of improper configuration or maybe a package that has side effects.
Anyway feel free to ping me if you ever had this issue in the future.
@themsaid dude, please don't come here and close my issue when I spent all that time typing out and CLEARLY showing my configuration which is configured properly and NO packages installed. Just because you "never had this problem" has nothing to do with others including myself, having this problem. Do you understand what a bug is? I have over 35 laravel apps running on this machine. All are 5.2 and below. The one 5.3 app I have running has this issue.
This is how projects end up sucking. When people like you want to close the issue so fast you don't take the time to understand the problem or why it's happening. I like using Laravel too much to have little peeons like you come and just casually say "maybe a package that has side effects" if you took the 2 seconds to read my post you'll see I HAVE NO PACKAGES installed.
Additionally, I'm clearly not the only person having this issue. It's not a one off it's a serious problem affecting multiple users and is continuously being swept under the rug because you don't know wtf you're doing so you Close it because "I have many apps running and never had this problem" I don't give a fuck what you have running. I've shown my configuration and I've shown the issue how about you try to fucking fix it before closing the issue?
Re-open this until it's been fixed. Or better yet why don't you step down because it's clear you dont' deserve to be a member of the framework.
I've been testing on a new install and I copied over all my files and it's working
Clearly something happened in your application down the road that lead to this behaviour, it's really hard to fix something we can't replicate, if on a fresh installation using the same config the issue doesn't show up that means we have something missing and it'll be really hard to figure out what's wrong in such situation.
It's been a while now since the issue is closed, please let me know if you ever found out what lead to this situation.
@astr0naugh7
I had the same/similiar issue after i changed group ownership of the cache/session storage folders from apache to a custom group (then adding apache user to that custom group).
Was drivin me nuts for about an hour before I remembered to restart apache (duh) and clear the existing cache and sessions.
sudo rm -rf storage/framework/sessions/*
sudo php artisan cache:clear
Tada! Working again.
Not sure if this is your problem or not, but I'd wager you may be in the same boat as I was especially if you're just using a stock install with make:auth.
-voxx
@astr0naugh7
I faced a similar issue and it was really annoying how it kept happening.
So i dedicated sometime to do a research, and found a solution.
The error is pretty logical and its good for security reasons.
It my case and i believe in many case the error appear when the session time out.
So when you revisit the page the new form token is generated which will be different from the session token hence an Exception is thrown to tell you that Token is mismatched.
In my research there are two solution you can implement to solve this problem.
One i think you already tried.
public function handle($request, Closure $next)
{
if($request->input('_token'))
{
if ( \Session::getToken() != $request->input('_token'))
{
return redirect()->guest('/')
->with('global', 'Expired token found. Redirecting to /');
}
}
return parent::handle($request, $next);
}
On personal note i think the approach above is cool hack but i don't think it is help full in all case,
Since the form can be of different purpose. Or you can tweak it a little bit by doing this instead.
return redirect->back()->withInput(Input::except('_token'))->withErrors($errors);
Take a look at my answer in stackoverflow
I hope somehow the information i shared is useful to you.
@astr0naugh7 , please check for spaces in your routes/web.php file. i had the same problem and a space before the opening tag
i have the same problem also, but the problem cause by my javascript error and affect this issue. maybe you can check is your javascript run on no error.
I too have the same problem. But this is since I started using virtual hosts(I assume). And that too, not even a single form with csrf token are working. And one more thing is I broke things while configuring virtual hosts and reinstalled apache and php. I am using arcclinux. I think i have a some configuration problem. Hope I get an answer here
I have the same problem.
clearing the cache helped me.
php artisan cache:clear
I have the same problem..
I solved this problem. I edited this file config->session.php
'domain' => env('SESSION_DOMAIN', null),
Remove SESSION_DOMAIN from the file (.env)
and composer dumpautoload
I have the same problem. It's not good enough to just say, "it's your config, we're just fine". If it might be that then you need to make an effort to alert the user to the problem. There are just too many incidents occurring to be brushed off as user error. Laravel has to be bullet proof. Please take this seriously.
The thing is if you have a 1000 devs customizing laravel, there's no way to pinpoint what each of them may have done to cause the error. There's so many possibilities. And for every developer that has left a message here saying there's a problem, there's 20 more that didn't have a problem. So without everyone sharing their entire code base and someone taking the time to peruse it, there's not really much that can be done. It boils down usually, as u can see by reading follow-up comments, to something being configured wrong. That's about as much info as can usually be given based on "same here" or "+1" or "I have the same problem". It's not being rude and not wanting to help, it's just that's really about all that can be done.
@devcircus Sure, I understand the point you make. I have been working for major global software suppliers since 1985, and I agree, in many cases, you are correct. However, for every developer who goes to the effort of leaving a message here there are 20 more who have not bothered.
We all know developing s/w is hard, no less so for those who build frameworks. Be careful not to fall into the "Microsoft trap" of "it works over here, so it must be your config" . As much as this might be true, over the long run, this approach will only damage the reputation of Laravel. And so, as hard as it is to solve this problem (and others) some real heavy lifting must be invested to protect the user and most importantly Laravel from this kind of problem. As Laravel becomes more and more complex, this kind of problem will only multiply.
Never forget the developer makes use of Frameworks to make his life easier, not harder. If the developer has to spend more time understanding and unravelling the mysteries and complexities of a Framework then it defeats its purpose. I sense we are fast approaching that tipping point with L5.4. I am in the midst of upgrading from 5.1 to 5.4. So far it has been nothing but problems, errors, hours of reading literature. 5.1 was easy to understand. You knew where everything was and what it was doing. 5.4 appears to have a mind of it's own, dynamically inventing it's routes, files and class entries. Half the time you don't know what is going on nor why. Add more features and with it more complexity, but at the very, very minimum, the documentation must be much, much more thorough. Laravel should not rely upon Stack Overflow to solve it's user problems. Better still, add software protections to alert users to problems AND solutions.
So, In conclusion, do not fall into the trap of delivering ever more features when the features you have can not and are not being effectively used by the developer community, for there in lies the "death by Microsoft". Thanks for reading this much. Cheers !
Comment the App\Http\Middleware\VerifyCsrfToken::class line from App\Http\Kernel.php.
It will disable the csrfToken check in the session.
It worked for me.
when i use php artisan serve
and use site at 127.0.0.1:8000 everything works fine but when is custom domain there is token error
Hello, my solutions is the next:
public function handle($request, Closure $next)
{
if (
parent::isReading($request) ||
parent::runningUnitTests() ||
parent::shouldPassThrough($request) ||
parent::tokensMatch($request)
) {
return parent::addCookieToResponse($request, $next($request));
}
return back()->with('error','The token has expired, please try again.');
}
Insert this code in app/Http/Middleware/VerifyCsrfToken.php is't a a override of the method de class parent.
Regarts
I had a similar problem and it turns out that my problem was in the file Kernel.php
protected $middleware = [
\Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
\Illuminate\Foundation\Http\Middleware\ValidatePostSize::class,
\App\Http\Middleware\TrimStrings::class,
\Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
];
These two lines:
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
Were also included in:
protected $middlewareGroups = [
'web' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
// \Illuminate\Session\Middleware\StartSession::class,
// \Illuminate\Session\Middleware\AuthenticateSession::class,
// \Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
\Illuminate\Routing\Middleware\SubstituteBindings::class,
]
Since the first declaration already applies all Middlewares to every request i guess they are not needed in the WEB group i commented them out. Including them two times was probably causing some sort of conflict and i left them global because my login route isn't part of the WEB group.
I hope i explained my problem clearly enough and that it helps you solving yours.
php artisan cache:clear
Fixed it for me. It happen suddenly, without changing anything.
I just have the same problem, and finally I found the answer !
So simple, just add this {!! csrf_field() !!} on your form.
It worked for me :+1:
Hello I had the same problem, I solved it by giving the write permission to storage folder.
sudo chmod - R o+w storage
This worked for me, I am running ubuntu server, and all the forms should have {{csrf_field()}}
I had the same issue in my app, I tryed to solve this problem but nothing works. Then I created a new project in laravel 5.4.23, then I executed the 'php artisan make:auth' command, then I copyed all my files in the app (eg models, migrations, controllers, composer.json, package.json, etc) to the new project in laravel 5.4.23, then I ran the app in a server on production mode and the error disappeared.
I don't know why but the problem is solved.
I hope this will help you to solve the problem here.
Furthermore my app in local mode (homestead environment) works fine all the time, the error occurs when I tryed run the app in the server on production mode for first time.
Ended up with changing SESSION_DRIVER in .ENV from 'file' to 'database'. For some reason my `storage/session/....'-files were created empty.
I had the same issue. All my laravel 5.4 applications started throwing this error whenever is submitted a form for some reason, including apps that i had built and forgotten about. i tried everything else on this forum and it didn't work until i came across a solution on stack overflow.
i replaced
{{ csrf_field()}}
in my form fields with
<input type="hidden" name="_token" value="{{ csrf_token() }}">
and voila, it works again!! hope this helps you
here is a link to the solution https://stackoverflow.com/questions/43202606/csrf-form-verification-laravel-error/43216302#43216302
Had the same issue, solved it by re-running php artisan make:auth
I'm facing the same issue.
When I try to move Auth::routes();
to the top of web routes, it works.
<?php
/** routes/web.php */
Auth::routes();
/** Start to register your web routes from here */
Setting the permissions above worked for me!
sudo chmod - R o+w storage
I think this problem happened because the browser block the Cookies files if your enable cookies this problem will if cookies is enabled then clear all cookies is the second way to solve this problem
This work for me
The csrf field is not working with cookes if you are using a normal php form, so it should not matter.
I have tried everything but nothing is working...
First i ran php artisan cache:clear
and then i cleared my browser's cookies since the beginning of time.
My app works, though i am not sure if php artisan cache:clear
did something or not
UPDATE:
The above process works for only one request. I get Token Mismatch Exception again after clearing the cookies. This time what i did was, i removed the EncryptCookies Middleware from my routes. By default, Laravel 5.3 applies a 'web' middleware group using the RouteServiceProvider. I went to app/Http/Kernel.php and removed 'App\Http\Middleware\EncryptCookies::class,' line and it works.
when i use php artisan serve and use site at 127.0.0.1:8000 everything works fine but when is custom domain there is token error
@owaishanif786 I have same error here, do you find any way to work with a custom domain?
I use a MAMP stack. In my case, this issue arose from not getting the correct group permissions set up for the /storage/* files and folders. Make sure your apache user has read / write access in that directory tree. On my Mac that was:
sudo chown -R dan:_www storage
sudo chmod -R g+w storage
Hope this helps someone.
i cause for my , when i dont close admin area then i new tab login in another user login
@themsaid I get sporadic reports of this on a live server (a few every day, 10000+ users). I guess it happens when they leave a page open for too long, and the next ajax request triggers this error as the session/token has expired? it is set to 24 hours at the moment, I agree with @mtuchi on this.
I fixed it by disabling SELinux (setenforce=0) still dont get why it wouldnt work with it enabled?
I am been working in node/express for years now and started helping a friend with a Laravel project cause it need some extra love.
This entire thread is wild. Why can't some tests be written to fix this and pinpoint a fix more easily? There are like 15 answers on a fix above and they are all drastically different.
My solution was also different, reading _mtucci's solution_, I tried to clean the column in databate that the function was looking to compare tokens, it worked on a dev server, but I don't think this is the best approach to a prod env. Anyway, I think this could help someone here.
Verify in your .env if your url of APP_URL is the same of etc/hosts.
In my case, this was down to using a non-secure connection with SESSION_SECURE_COOKIE
set to true. Might be worth checking if you're also having this issue.
I was having this issue with browserSync on, logging in through the original domain name and not proxied through localhost:3000 so that was causing session issues. No mismatch using :3000
I don't know if its relevant, but i'm having the same issue.
Apparently my server admin enforce something about header (i don't understand about header stuff) that breaks laravel's csrf token.
This is the header response that causes the error :
```date:
Thu, 15 Mar 2018 10:39:08 GMT
server:
Apache
x-frame-options:
SAMEORIGIN
referrer-policy:
same-origin
cache-control:
no-cache, private
vary:
Accept-Encoding
x-xss-protection:
1; mode=block
set-cookie:
XSRF-TOKEN=redacted; expires=Thu, 15-Mar-2018 12:39:08 GMT; Max-Age=7200; path=/; domain=redacted;HttpOnly;Secure; laravel_session=redacted; expires=Thu, 15-Mar-2018 12:39:08 GMT; Max-Age=7200; path=/; domain=redacted; HttpOnly;HttpOnly;Secure
content-security-policy:
default-src 'self'
x-content-type-options:
nosniff
content-length:
4294
content-type:
text/html; charset=UTF-8
And this is after he fixes it :
date:
Thu, 15 Mar 2018 11:28:01 GMT
server:
Apache
x-frame-options:
sameorigin
x-content-type-options:
nosniff
x-xss-protection:
1; mode=block
x-permitted-cross-domain-policies:
master-only
cache-control:
no-cache, no-store, must-revalidate; no-cache, private
pragma:
no-cache
expires:
-1
content-security-policy:
style-src * 'unsafe-inline' 'unsafe-eval'
set-cookie:
XSRF-TOKEN=redacted; expires=Thu, 15-Mar-2018 13:28:01 GMT; Max-Age=7200; path=/; domain=redacted; laravel_session=redacted; expires=Thu, 15-Mar-2018 13:28:01 GMT; Max-Age=7200; path=/; domain=redacted; HttpOnly
vary:
Accept-Encoding
content-length:
4294
content-type:
text/html; charset=UTF-8
```
I don't know if its relevant as i don't know anything about server settings. But after the change it solve the problem.
Please take care of {{csrf_field ()}} is inside the login form
Go to laravelFolder/bootstrap/cache then rename config.php to anything you want eg. config.php_old and reload your site. That should work like earthquake
@antoniogocaj out of every comment here, your solution worked for me, there were a couple of empty lines before the start of my
in laravel 5.5 solved !
@Denerot anything outside of (or before) php tags gets outputted to the response.
i would expect the problem here is likely that those new lines were being outputted before / during the headers, which is breaking cookies.
the crsf token error is because session isnt working correctly. one way this can happen is browser not having session cookie correctly.
I would like to leave my two cents here: I moved my application's code and I had changed the
'domain' => 'livedomain.com'
in session.php
's file. What I did to get it to work both in my test and prod enviroment was: 'domain' => env('DOMAIN', 'livedomain.com'),
Hope it helps someone.
I also encountered this problem because I changed session.php to cause this problem
Yeah this is weird. I'm using Homestead. Everything work perfect when I'm accessing the app from the url in my hosts file. However, when I do share http://mysite.local and try access it through the ngrok.io url I run into this issue. I tried most things people mentioned above, even changing the APP_URL to the ngrok.io url and still no luck. Any Ideas on this only happening when sharing with vagrant? I also have other sites on my computer that do work with vagrant share. Not sure what I messed up here.
Edit: In my case, my login.blade.php had a form action of {{ route('login') }} so it was posting to the named route. When using vagrant share, if you change the form action to /login it will post to the ngrok.io url.
Check if cookies are enabled in the browser
Or close tab and open new window your site
I had is a problem in browser Opera
I had same problem one in a while. Solution was to manage logs, as they grow rapidly (they used 100% of server storage, which should explain why storing tokens at your local environment works fine, but doesn't work on client's server).
Try to remove them (storage/logs/laravel.log), or try some of the other strategies described at https://laravel.com/docs/5.7/logging
Setting the permissions above worked for me!
sudo chmod - R o+w storage
sudo chmod -R o+w storage
Verify if you have more then one laravel frameworks at the same folder. I don't know why, but laravel have a problem with it.
If u can't remove one system of folder to test, do it:
Edit the file config/session.php
and change the destination path of session
from
'files' => storage_path('framework/sessions'),
to
'files' => storage_path('framework/sessions/newfolder'),
if the systems use the same host, change the line:
'path' => '/' . env('APP_URL', ''),
to
'path' => '/yourSystemName' . env('APP_URL', ''),
Clean your cache, run composer dumpautoload, etc etc, reload and everything
@DanSorahan
In my case, this was down to using a non-secure connection with
SESSION_SECURE_COOKIE
set to true. Might be worth checking if you're also having this issue.
YES! Thank you! Just had a new VM configured and they hadn't applied the SSL cert yet. This fixed my issue perfectly!
Try it it will solve your problem, It is because of http and https conflict.
Goto "session.php" file change this: 'secure' => env('SESSION_SECURE_COOKIE', false), to this: 'secure' => true,
I solved this problem. I edited this file config->session.php
'domain' => env('SESSION_DOMAIN', null),
Remove SESSION_DOMAIN from the file (.env)
and
composer dumpautoload
I had the same issue, that was because of the Session Domain. I deleted it from the .env file and it works fine now.
@astr0naugh7
I had the same/similiar issue after i changed group ownership of the cache/session storage folders from apache to a custom group (then adding apache user to that custom group).
Was drivin me nuts for about an hour before I remembered to restart apache (duh) and clear the existing cache and sessions.
sudo rm -rf storage/framework/sessions/*
sudo php artisan cache:clearTada! Working again.
Not sure if this is your problem or not, but I'd wager you may be in the same boat as I was especially if you're just using a stock install with make:auth.
-voxx
Thank
In my case, this was down to using a non-secure connection with
SESSION_SECURE_COOKIE
set to true. Might be worth checking if you're also having this issue.
This one solved my issue. Many thanks! :)
Most helpful comment
@themsaid dude, please don't come here and close my issue when I spent all that time typing out and CLEARLY showing my configuration which is configured properly and NO packages installed. Just because you "never had this problem" has nothing to do with others including myself, having this problem. Do you understand what a bug is? I have over 35 laravel apps running on this machine. All are 5.2 and below. The one 5.3 app I have running has this issue.
This is how projects end up sucking. When people like you want to close the issue so fast you don't take the time to understand the problem or why it's happening. I like using Laravel too much to have little peeons like you come and just casually say "maybe a package that has side effects" if you took the 2 seconds to read my post you'll see I HAVE NO PACKAGES installed.
Additionally, I'm clearly not the only person having this issue. It's not a one off it's a serious problem affecting multiple users and is continuously being swept under the rug because you don't know wtf you're doing so you Close it because "I have many apps running and never had this problem" I don't give a fuck what you have running. I've shown my configuration and I've shown the issue how about you try to fucking fix it before closing the issue?
Re-open this until it's been fixed. Or better yet why don't you step down because it's clear you dont' deserve to be a member of the framework.