Yet another verifycsrf token issue

Published 1 week ago by maisnamraju

I have a laravel 5.4 application i upgraded from 5.2 recently and am having issues with the session tokens and csrf token are not the same in production at times (I am using laravel forge for deployment) . so far I have done the following

{
    $token = $request->session()->token();

    $header = $request->header('X-XSRF-TOKEN');

    return StringUtils::equals($token, $request->input('_token')) ||
           ($header && StringUtils::equals($token, $this->encrypter->decrypt($header)));
  1. clear cache and run config:cache ( this solves my issues for a while but it works and then doesn't work)
  2. I have tried all the session drivers, the results are the same
  3. chmoded the storage folder though this is not needed in a forge setup.

What i have noticed is that the session token keeps on changing with the csrf token remains the same.

I am so frustrated at this that I may just quit laravel for good as this just keeps happening every other time and am not able to determine whats causing this.

jlrdw
jlrdw
1 week ago (156,470 XP)

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

Snapey
Snapey
1 week ago (523,835 XP)

Yet others NEVER have an issue....

(session token WILL change on every request)

maisnamraju

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

jlrdw
jlrdw
1 week ago (156,470 XP)

@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.

maisnamraju

@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.

jlrdw
jlrdw
1 week ago (156,470 XP)

@maisnamraju please post back if you get problem resolved.

Snapey
Snapey
1 week ago (523,835 XP)

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.

Snapey
Snapey
1 week ago (523,835 XP)

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?

Snapey
Snapey
1 week ago (523,835 XP)

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

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

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

Snapey
Snapey
1 week ago (523,835 XP)

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),
maisnamraju

@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.

beitsafedaniel

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.

Sign In or create a forum account to participate in this discussion.