Session resets on every page reload

Home / Uncategorized / Session resets on every page reload

Question:
I was developing a laravel application on my windows machine and project was working fine there. The project was synced with dropbox and when i moved to mac my laravel project is not working here on macos.
The issue i am facing is that it regenerates session id on each page reload. I am using database as session storage and it adds a new entry in database.
I have tried using file driver as session storage and same thing happens that it creates a new file in storage/framework/session which justifies that file permissions are ok and writeable.
All of my forms have stopped working and getting
TokenMismatchException in VerifyCsrfToken.php

Permission of storage folder and session folder is 755

Each reload on the application adds a new entry in the db as i am using database driver to save session

Below is my session file
env(‘SESSION_DRIVER’, ‘file’),

/*
|————————————————————————–
| Session Lifetime
|————————————————————————–
|
| Here you may specify the number of minutes that you wish the session
| to be allowed to remain idle before it expires. If you want them
| to immediately expire on the browser closing, set that option.
|
*/

‘lifetime’ => 120,

‘expire_on_close’ => false,

/*
|————————————————————————–
| Session Encryption
|————————————————————————–
|
| This option allows you to easily specify that all of your session data
| should be encrypted before it is stored. All encryption will be run
| automatically by Laravel and you can use the Session like normal.
|
*/

‘encrypt’ => false,

/*
|————————————————————————–
| Session File Location
|————————————————————————–
|
| When using the native session driver, we need a location where session
| files may be stored. A default has been set for you but a different
| location may be specified. This is only needed for file sessions.
|
*/

‘files’ => storage_path(‘framework/sessions’),

/*
|————————————————————————–
| Session Database Connection
|————————————————————————–
|
| When using the "database" or "redis" session drivers, you may specify a
| connection that should be used to manage these sessions. This should
| correspond to a connection in your database configuration options.
|
*/

‘connection’ => null,

/*
|————————————————————————–
| Session Database Table
|————————————————————————–
|
| When using the "database" session driver, you may specify the table we
| should use to manage the sessions. Of course, a sensible default is
| provided for you; however, you are free to change this as needed.
|
*/

‘table’ => ‘sessions’,

/*
|————————————————————————–
| Session Cache Store
|————————————————————————–
|
| When using the "apc" or "memcached" session drivers, you may specify a
| cache store that should be used for these sessions. This value must
| correspond with one of the application’s configured cache stores.
|
*/

‘store’ => null,

/*
|————————————————————————–
| Session Sweeping Lottery
|————————————————————————–
|
| Some session drivers must manually sweep their storage location to get
| rid of old sessions from storage. Here are the chances that it will
| happen on a given request. By default, the odds are 2 out of 100.
|
*/

‘lottery’ => [2, 100],

/*
|————————————————————————–
| Session Cookie Name
|————————————————————————–
|
| Here you may change the name of the cookie used to identify a session
| instance by ID. The name specified here will get used every time a
| new session cookie is created by the framework for every driver.
|
*/

‘cookie’ => ‘laravel_session’,

/*
|————————————————————————–
| Session Cookie Path
|————————————————————————–
|
| The session cookie path determines the path for which the cookie will
| be regarded as available. Typically, this will be the root path of
| your application but you are free to change this when necessary.
|
*/

‘path’ => ‘/’,

/*
|————————————————————————–
| Session Cookie Domain
|————————————————————————–
|
| Here you may change the domain of the cookie used to identify a session
| in your application. This will determine which domains the cookie is
| available to in your application. A sensible default has been set.
|
*/

‘domain’ => env(‘SESSION_DOMAIN’, null),

/*
|————————————————————————–
| HTTPS Only Cookies
|————————————————————————–
|
| By setting this option to true, session cookies will only be sent back
| to the server if the browser has a HTTPS connection. This will keep
| the cookie from being sent to you if it can not be done securely.
|
*/

‘secure’ => env(‘SESSION_SECURE_COOKIE’, false),

/*
|————————————————————————–
| HTTP Access Only
|————————————————————————–
|
| Setting this value to true will prevent JavaScript from accessing the
| value of the cookie and the cookie will only be accessible through
| the HTTP protocol. You are free to modify this option if needed.
|
*/

‘http_only’ => true,

];

As i mentioned same project is running fine on my windows machine and not working on my macos due to session issue. I tried many solutions online but nothing worked for me.


Answer:
This looks to me like a variation of a long time issue when using cookies with localhost as a domain. In short, you can’t do it, because in many browsers a domain name requires 2 ‘.’ characters in the domain name at minimum.

These are ok:www.domain.com
.domain.com

This issue has been discussed in various places, and in particular to php (which Laravel is beholden to) in the manual and comments for set cookie and in particular the section on ‘domain’:

The (sub)domain that the cookie is available to. Setting this to a subdomain (such as ‘www.example.com’) will make the cookie available to that subdomain and all other sub-domains of it (i.e. w2.www.example.com). To make the cookie available to the whole domain (including all subdomains of it), simply set the value to the domain name (‘example.com’, in this case).

Older browsers still implementing the deprecated ยป RFC 2109 may require a leading . to match all subdomains.

A simple way around this, is to put an alias in your /etc/hosts file for a domain of your choosing. The best option, according to rfc2606 is to use .test at the TLD.
// /etc/hosts
127.0.0.1 localhost www.yourbogusdomain.test

Just as an aside, reasons like this are why I use Vagrant/virtualbox/docker. You are probably going to be hosted on a linux server, so why develop on Windows/Mac OS, using a bunch of workarounds, along with WAMP/MAMP/whatever clogging up your machine with services that you will have to start/stop all the time, not to mention install/upgrade?

Last but not least, virtualization and the networking options it provides allow you to setup clusters and test out advanced multi-host configurations that would be messy at best to try and configure on your workstation as a series of interconnected processes.
Read more

Leave a Reply

Your email address will not be published. Required fields are marked *