Yet another verifycsrf token issue

Published 10 months 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
10 months ago (223,660 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
10 months ago (926,315 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
10 months ago (223,660 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
10 months ago (223,660 XP)

@maisnamraju please post back if you get problem resolved.

Snapey
Snapey
10 months ago (926,315 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
10 months ago (926,315 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
10 months ago (926,315 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
10 months ago (926,315 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.

Please sign in or create an account to participate in this conversation.