Session token regenerated on each new page load

Are the cookies getting written to the filesystem ok?

Please post the values (without comments) from session.php.

Hi Rob!

Thanks for replying. The sessions are being written, I see some from today and yesterday in storage > framework > sessions

return [

    'driver' => env('SESSION_DRIVER', 'file'),

    'lifetime' => 120,

    'expire_on_close' => false,

    'encrypt' => false,

    'files' => storage_path().'/framework/sessions',

    'connection' => null,

    'table' => 'sessions',

    'lottery' => [2, 100],

    'cookie' => 'laravel_session',

    'path' => '/',

    'domain' => null,

    'secure' => false,

];```

Yep I tested it in multiple browsers and on a staging server too.

The only time session is used is when data is being pushed into it or being retrieved to be output in a view e.g Session::push('items', $item); and $item = Session::get('items')[$id]; which is passed to an edit view. Unset is used to remove items from the sessions when an order is submitted but these shouldn't affect anything from selecting an item from a list and going to the view to enter the item details.

The only packages I'm using at the moment is illuminate/html

I haven't created a vanilla Laravel install no,

Laravel doesn't use PHP $_SESSION stuff, make sure your method for sessions is writable/readable. Normally /storage/framework/sessions

Hi Bashy,

Yes it's writeable, as I'm seeing new files being created there. What permissions should this directory have so I can double check it's readable?

To answer one of your original questions, Laravel doesn't change the token on each reload.

I have a vanilla L5 installation on Homestead with the below code in routes.php

Route::get('session', function() {
    return Session::all();
});

The first time I hit this route I see a file created in /storage/framework/sessions but no further files are created on subsequent reloads. The token returned is always the same.

What result do you get when you run this?

Hey Rob,

An update: In the last few mins I ran a flush on a session on the server and that seems to solve the problem for me in my browser but if I ask a colleague to open the app (they had never accessed it before) and try to submit a form they get the token mismatch exception. What's weird is how it fixes the problem. I'm not sure if that info would help track down the cause of the issue.

I think the issue on homestead was that I needed the session had expired and needed to be flushed and a new one created.

Also to add to that above, when I try the app on a machine that hadn't accessed it yet I see new session files being added at every request. So I load up a page on the phone, cd into the sessions storage directory and run ls -a I see a new file added for every time I hit a different page or refresh a page.

Example of one of the files with permissions and owner.

-rw-r--r-- 1 forge forge 257 May 28 14:10 load of hash*

Could you show the content of 2 subsequent session files? Maybe they hold a clue.

Also, are you using sub-domains - or differing domains on the same app and somehow making requests to those different domains - through Ajax maybe?

Hi @sitesense

No problem:

a:4:{s:6:"_token";s:40:"jmj4cc1I2W92mUsoKzNDx4yKCCuDgTBgLqQDcLZP";s:9:"_previous";a:1:{s:3:"url";s:75:"http://urlwashere/page";}s:9:"_sf2_meta";a:3:{s:1:"u";i:1432820879;s:1:"c";i:1432820879;s:1:"l";s:1:"0";}s:5:"flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}}

and

a:4:{s:6:"_token";s:40:"mRGo46o7sEAd47zUOgmzr8G8Jb7kAvAPJe2CqTtv";s:9:"_previous";a:1:{s:3:"url";s:20:"http://urlwashere";}s:9:"_sf2_meta";a:3:{s:1:"u";i:1432820872;s:1:"c";i:1432820872;s:1:"l";s:1:"0";}s:5:"flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}}

Not using Ajax at all. I've just come across this, not sure if it's the same issue https://github.com/laravel/framework/issues/8172

I've seen that issue myself but it's not the same. Your sessions are regenerating with each request. The issue on Github is that some session writes are being lost because they are rewritten by an existing request when it completes.

@sitesense OK cheers for clearing that up.

In my sessions.php config should I be setting the domain or is it ok to leave it null? That wouldn't be causing the issue would it?

You can try setting the domain but I've never had to. Null seems to work fine.

On the subject of the domain though, that's the only thing I find odd about your session files.

I notice that there is no .dev, .app, .com etc.

I wonder if that is causing some confusion and the session handler can't reliably determine the domain.

@sitesense Are you referring to the previous URL in the session? I removed the IP address and replaced it to keep the URL private. It's using an IP address on staging, locally it's just homestead.app

I was referring to these:

http://urlwashere/page

http://urlwashere

There is no . suffix. I thought that could cause a problem if the session handler matches domains and they can't be resolved into one because a dot can't be found.

@sitesense Yeah there's really an IP address there, I just had to take it out for privacy.

Have you modified the VerifyCsrfToken.php in middleware at all?

It looks like this by default:

<?php namespace App\Http\Middleware;

use Closure;
use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as BaseVerifier;

class VerifyCsrfToken extends BaseVerifier {

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        return parent::handle($request, $next);
    }

}

@LindenWalsh If you run my little code snippet then you should be able to determine if the issue is happening very early on in the code execution (therefore perhaps a server/Laravel issue) or whether other code in controllers, middleware etc is causing the issue.

@sitesense Nope, checking it just there was the first time I opened the file.

Please post the cookies that are created for your app, that way we can see what domain or settings it has attached to it.

Example

@robgeorgeuk I actually had that same session route already set up during development. And visiting it has the same result as the flush route I also have, it fixes the problem but obviously only for me so once the site is in production others will have the same issue with the token mismatch exception. But yeah that seems to kick the session off and it persists after that.

To me it seems like I"m missing something basic in starting the session which I don't think I need to do, do I? I thought the session is created by default when the app loads.

@bashy

Here's the screenshot, I had to blur the domain but they're both the same e.g both example.com

Just a note, it's on the left as well. Can't see it all though.

So that gets refreshed every load? You may need to find where it's checking sessions and not finding one. Maybe make a page to set/read it.

@bashy You might take a look at my reply to robgeorgeuk above my reply with the screenshot as I think I might be messing up something basic here.

So if I inspect the cookies on a browser with the problem no cookies are being set, only when I hit /session which is just a closure that returns Session::all(); and go back to the app I see cookies then.

Okay, what session driver are you using?

This doesn't tell me if you have some ENV setting it

'driver' => env('SESSION_DRIVER', 'file'),

@bashy I haven't set an environment variable with forge, I assumed that it falls back to file if it's not set, is that wrong?

Ah okay, no that's fine. So is that different than dev environment? If it's working locally but not production, it's something to do with the PHP/web server environment I guess?

@bashy I'm having the same issue locally. I thought I wasn't but I need to flush the session or visit /session to get things working.