Yet another verifycsrf token issue

There have be dozens of issues here, a real mess it seems. You may want to search stackoverflow to see if there has been a good solution for laravel 5.4. Please post a solution here if you find one that works.

Seems a once a week thing.

Also found https://github.com/laravel/framework/issues/16064

Yet others NEVER have an issue....

(session token WILL change on every request)

@Snapey, you can check the whole list yourself. https://github.com/laravel/framework/issues/16064

@Snapey @maisnamraju I'm not saying there's nothing wrong with your setup (config), but yes session token WILL change on every request, but the token in a post should also change for the match (test when posted token = session token). Just seems a lot of people are having trouble.

I confess, most of the "built-in" stuff I don't use or like. I write my own Auth and my own csrf routines based on Chris Shiflet articles. They are sound and good.

Quick example from a custom framework controller:

$token = Cln::setToken();
Session::set('token', $token);
// other code
View::layoutMake($path, null, $layout, $title, $token, $dog);

In view:

//code
<input type="hidden" name="token" value="<?php echo $token; ?>" />
//code

Back in controller after form is posted:

if (isset($_POST['submit'])) {
            $mytkn = Session::get('token');
            $hastoken = Cln::fixTok($mytkn);
            if ($hastoken == "notvalid") {
                Session::set('token', md5(uniqid(rand(), TRUE)));  
                 // to spoil a spoof. To make sure no match if a problem.
            }
            if ($_POST['token'] != Session::get('token')) {
                Url::redirect('admin'); // or to where ever.
            }
// all good continue on

The fixTok function

public static function fixTok($tosess = null)
    {
        $tosess = (is_null($tosess) || empty($tosess) || strlen($tosess) < 1 ? 'notvalid' : trim($tosess));
        return $tosess;
    }

Tested with fake and no tokens passed, all works good.

@jlrdw Thanks, but I don't have the option at the moment to write my own authentication. But ill keep this in mind in the future.

@maisnamraju please post back if you get problem resolved.

sorry but if you read that github issue, apart from the first poster it's just full of people saying things like, oh, forgot to add csrf_field, or cleared session and now it's ok, or worse still just comment out the middleware.

I can't see anything there that backs up your claim that loads of people are having this issue.

Not to say that I don't hear that YOU have an issue.

Why do you expect session and csrf tokens to be the same?

Try the following in your .env file (assuming session.php is standard)

  APP_URL=http://yoursitename.dev
  SESSION_DOMAIN=yoursitename.dev

Having similar issues.. Either we're doing something wrong, a package is hurting us, or there is actually a bug in Laravel nobody of the devs wants to acknowledge..

https://laracasts.com/discuss/channels/laravel/auth-not-working-on-other-computer

Did some experimentation into SESSION_DOMAIN

This might not help you but may help others coming to this post in the future.

If SESSION_DOMAIN is set to anything then it needs to match exactly the domain you are using, or the root domain if using a subdomain. Otherwise cookies are generated for session and csrf but then not returned to the server when submitting a form because they don't match the servers domain.

If SESSION_DOMAIN is omitted then the browser will always use the same domain.

If you don't have SESSION_DOMAIN in the .env file, check also that the config/session.php file has not been changed. It should be set to null in order to not impose a domain. e.g.;

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

@Snapey I have tried all the solutions plus more including the one you posted. I have given up on Laravel and Spark altogether, its just not for me.

We had this issue, it took about 8 hours over 2 days to work out that the controllers were closed. Technically a pure php file shouldn't be closed, it hasn't been an issue up until now, why now i don't know, but i can tell you we fixed these issues by going through all .php files and removing the ?> from the end. We use Phpstorm and it was quite simple using the "find in path" option.