Integrity constraint violation when using database session driver

[thewinterwind]

Experienced this in 5.0 and 5.1

MySQL version: 5.6
Forge provisioned server.

We use Galera Cluster for MySQL, but each site reads and writes from only one database. I don't think that would have anything to do with this error. I used artisan session:table to create the table so everything is standard schema-wise. Happens quite intermittently, about once per day.

Illuminate\Database\QueryExceptionGET /diaz/edit
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4c1698dcfe5da87c5f77c90592855490817e575d' for key 'sessions_id_unique' (SQL: insert into `sessions` (`id`, `payload`, `last_activity`) values (4c1698dcfe5da87c5f77c90592855490817e575d, YTo1OntzOjY6Il90b2tlbiI7czo0MDoid1NLSjlmNGFxUml4RkowRVVkU0M3UjhNdldhWlZEY2hwTDhrbEU3YSI7czo3OiJtZXNzYWdlIjtzOjI2OiJMb2dpbiB0byBlZGl0IHlvdXIgcHJvZmlsZSI7czo1OiJmbGFzaCI7YToyOntzOjM6Im5ldyI7YTowOnt9czozOiJvbGQiO2E6MTp7aTowO3M6NzoibWVzc2FnZSI7fX1zOjk6Il9wcmV2aW91cyI7YToxOntzOjM6InVybCI7czozNzoiaHR0cHM6Ly9tYW5pbGEuZXNjb3J0cy5saWZlL2RpYXovZWRpdCI7fXM6OToiX3NmMl9tZXRhIjthOjM6e3M6MToidSI7aToxNDM0MTY4Njc0O3M6MToiYyI7aToxNDM0MTY4Njc0O3M6MToibCI7czoxOiIwIjt9fQ==, 1434168674))

[rkgrep]

Is it possible that insert quieries are not written immediately but with some latency?

[thewinterwind]

yes but not much. I am not caching config.

[GrahamCampbell]

You probably need to cache config. That fixes most issues I see like this.

[ibrasho]

I'm using config:cache but I still see this issue every day or so.
We still relay on dotenv to populate server variables, so this might be the issue.

[rkgrep]

Why do you think it is a config cache issue?
I guess there may be some latency between sending response (with session ID) and app termination (when session is being saved to databse).

For example:

1. User sends request - session id created (session->exists == false)
2. User gets response (with generated session id).
3. Some ajax or another request catches session id (session->exists == false as the first request is not finished - session is not written).
4. One of requests terminates app (session written to database with INSERT)
5. Another request terminates with INSERT statement again (because session->exists is false in both cases)

Otherwise it may be database INSERT query latency so the second request executes SELECT before insert finishes.

[fer-ri]

Happened to me now after switched to database driver for session .. any idea?

Thanks

ping @taylorotwell

[mgrimard]

I am experiencing the issue as well, using the default session build with the DB.

[fer-ri]

👍

[deanmraz]

@GrahamCampbell why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver -> save method.

[taylorotwell]

This needs reopening.

On Jan 28, 2016, 5:18 PM -0600, Dean [email protected], wrote:

@GrahamCampbell(https://github.com/GrahamCampbell)why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver ->save method.

—
Reply to this email directly orview it on GitHub(#9251 (comment)).

[taylorotwell]

Does anyone have a solution?

On Jan 28, 2016, 5:18 PM -0600, Dean [email protected], wrote:

@GrahamCampbell(https://github.com/GrahamCampbell)why close this ticket, seems like lots of people are having issues with this problem and continue to have this problem. I think the issue lies in the database driver ->save method.

—
Reply to this email directly orview it on GitHub(#9251 (comment)).

[deanmraz]

Deployed this fix to my environment today. I will let you know if that resolves the issue.
#12059

[nolros]

@taylorotwell @GrahamCampbell

Laravel version 5.2.37

I've seen a number of these session integrity issues show up on laracasts, stackoverflow, etc. I ran into the same issue today and able to replicate to some degree. It seems to a session DB related issue vs. session file. To be honest it is not really a bug but a dev issue that can be solved with middleware. That said given the norm of multi device it might be something you want to look into, but unsure if even that applies.

REPLICATE: Let’s say you have a home.blade.php and second page called register.blade.php a route ‘/register’ which yields content from home. If you load /register from lets say from a MAMP stack everything will work fine as expected. Now while you still have that session, open a new browser tab. Make a copy of home.blade.php , lets say debug.blade.php which again yields to the same register.blade.php a route ‘/register’ and now if you load /register it will load register and will create the duplicate session id. Now if you go back to original tab and attempt to load register or you will get a DB session integrity duplicate issue. Which is why a number of bug complaints are login / logout related as I suspect is because they are directing to a different (duplicate) home page while still using the same session. Unsure what is causing the duplicate issue i.e if it is csrf token / session / DB session / home page issue.

Hope his helps.

[tuproyecto]

Any solution for this Bug?

[fer-ri]

👍

[GrahamCampbell]

Any solution for this Bug?

Not in 3 hours.

[nolros]

fwiw, I noticed I can also replicate it again by breaking a blade template load during ajax requests. For example if I force a blade template fails (e.g. wrong name) while I'm doing an ajax init() data load on vanilla route.

Route::get('/register', [ 'as' => 'getRegister', 'uses' => 'ApiController@getRegister', ]);

been trying to debug it further but none of angular / testing tools are giving me any additional insight. I do believe that to @rkgrep summary above that there is a session / queue issue / conflict and might be ajax related. In my case I have a number of angular services init ajax http requests and if the template fails i.e. exception and then attempt to reload . It returns the unencoded JSON with a 200 status code.

  javascript?v=1453465343:2050 Uncaught SyntaxError: Unexpected token < 

followed by a 

 angular.js:13642 SyntaxError: Unexpected token < in JSON at position 11625. 

the position 11625 is where the html document gets appended to the JSON data.

I think it is worth nothing that I get the following exception if it detects an existing session record, but I get the above silent fail if it has 2 existing session records i.e somehow the DB has written 2 identical session records and if it attempts to write a 3rd it fails silently and sends back JSON data but unencoded.

Next exception 'Illuminate\Database\QueryException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'a26e09eaf0a210a34e58ebab42acd9435681e0a5' for key 'sessions_id_unique' (SQL: insert into `sessions` (`payload`, `last_activity`, `user_id`, `ip_address`, `user_agent`, `id`) values (YTo0OntzOjY6Il90b2tlbiI7czo0MDoiOVE3M3ZLam12YlpFVEhLNDBSOVAwMDdIZWpKeGY0YUFNQVZDRTFJUCI7czo5OiJfcHJldmlvdXMiO2E6MTp7czozOiJ1cmwiO3M6MzI6Imh0dHA6Ly93d3cuY21vOjg4ODgvYXBpL3BlcnNvbmFzIjt9czo5OiJfc2YyX21ldGEiO2E6Mzp7czoxOiJ1IjtpOjE0NjU5MjE0ODU7czoxOiJjIjtpOjE0NjU5MjE0ODU7czoxOiJsIjtzOjE6IjAiO31zOjU6ImZsYXNoIjthOjI6e3M6Mzoib2xkIjthOjA6e31zOjM6Im5ldyI7YTowOnt9fX0=, 1465921486, , ::1, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36, a26e09eaf0a210a34e58ebab42acd9435681e0a5))' in /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Database/Connection.php:713 Stack trace: #0 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Database/Connection.php(669): Illuminate\Database\Connection->runQueryCallback('insert into `se...', Array, Object(Closure)) #1 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Database/Connection.php(442): Illuminate\Database\Connection->run('insert into`se...', Array, Object(Closure)) #2 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Database/Connection.php(398): Illuminate\Database\Connection->statement('insert into `se...', Array) #3 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(2039): Illuminate\Database\Connection->insert('insert into`se...', Array) #4 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Session/DatabaseSessionHandler.php(117): Illuminate\Database\Query\Builder->insert(Array) #5 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Session/Store.php(262): Illuminate\Session\DatabaseSessionHandler->write('a26e09eaf0a210a...', 'a:4:{s:6:"_toke...') #6 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(88): Illuminate\Session\Store->save() #7 /Users/nolros/Documents/cmo/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(155): Illuminate\Session\Middleware\StartSession->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response)) #8 /Users/nolros/Documents/cmo/public/index.php(58): Illuminate\Foundation\Http\Kernel->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response)) #9 {main}

here is an example of the ajax request

Request URL:http://www.cmo:8888/api/personas Request Method:GET Status Code:200 OK Remote Address:[::1]:8888 Response Headers view source Cache-Control:no-cache Connection:Keep-Alive Content-Type:application/json Date:Tue, 14 Jun 2016 16:24:45 GMT Keep-Alive:timeout=5, max=96 phpdebugbar-id:b73cf0e58e0f47fd49857463540cbaf3 Server:Apache Set-Cookie:laravel_session=a26e09eaf0a210a34e58ebab42acd9435681e0a5; path=/; httponly Set - Cookie:XSRF - TOKEN = eyJpdiI6Ijd2Y0pmN3JCSWRTNGE5dzFnT1FSSFE9PSIsInZhbHVlIjoiNWFubHNNYTVLeGRRc1B4RW9zMGNBQ3NVTFpDeTUrVkdzZWpWWjBRXC9scDlRejQ0TnpwNHQzV3BrUkJlamNUSm5jZjFudmFCM1VLb0dlUEhERHVPN0xRPT0iLCJtYWMiOiJjNTYxZDc3NmM0ZTI5M2MzNGI2ZmM3MDIxZGFjMDZiMzc1MGI1OTM4YWExOGI5NzczNTUzMzJiMmE3ZDkxZmRjIn0 % 3D; expires = Tue, 14 - Jun - 2016 18:24:46 GMT; Max - Age = 7200; path =/ Transfer-Encoding:chunked X-Powered-By:PHP/5.6.10 Request Headers view source Accept:application/json, text/plain, _/_ Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8 Cache-Control:no-cache Connection:keep-alive Cookie:cmosolution=eyJpdiI6IlBIYUhCQzJYUUxkMFwvZ0x2RmJraFhnPT0iLCJ2YWx1ZSI6IjVqaXA2ak9WN3laaHdVNkVtRVRPbVJOVThoRTVGV2E0K1RiTHdIcFQ4eGNCTU9nYjRnUnhVWEduODJvS1wvVW15QUlcL1ZyWlp0Z3o0MVhGem1rUzZPZjlLNEY5VTF3eW4zckE0ZXNHTHRCZXlOVVRDWkFoS3NlNHlBRVR3Y3IwdFkiLCJtYWMiOiI1NDcxNmRiZTBiN2NiMmQ5ODcwYTMyZDcxY2ZmYzFkMGU1NmRiNTc0MDAxNTBiMTVhZjNlZjJkMTljNjIyYmFlIn0%3D; remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6Im94R1B6NFwvUnpMQUp2M0VuTDN3cFlnPT0iLCJ2YWx1ZSI6IjNJZUVCSnFhR1IzZ0tVaVNTd3hUb1NcL2FIcHFcL1pJaE9FMGRIc2hQV1NDZzBycmVxN2xUb0s3aUdjWnpRaDFCWlwveHhCXC8xZG1wOE5WdnJpc0RYK094UGVMWDJ1cjNiSFE0R2tMM2VhRkJuVT0iLCJtYWMiOiJhMjMzYTFlNmM2MWIxNDJlNDQwZDJiZTNhNjhhNWFhNzRlZThiYjNhNjc1NDhiY2MxNjI0MTc2MGY3MDgwYWQxIn0%3D; XSRF-TOKEN=eyJpdiI6IlZ5bHZNNlVXM0ZqM0tWd0dheUtJUEE9PSIsInZhbHVlIjoieGdyYzRtOUFHaHptMGVYbUw1ZzNIVU5hTjQ5cDM1QWljNHBWazVWZVVZdXdBRnl1YWFpc1UzVE53Q0tlbGZLQUxVazdLcWZ0enZxWG5vUURGZHVcL2RnPT0iLCJtYWMiOiI3NDIxNDJmN2Q3NWYxYWE2MTY0NDc4MGM4ZWNkMzFiNDY3OWE3ZWExMmNiMDEzZDNiYjU1Njg4NGQ5NzJhZmMxIn0%3D; laravel_session=a26e09eaf0a210a34e58ebab42acd9435681e0a5 Host:www.cmo:8888 Pragma:no-cache Referer:http://www.cmo:8888/register User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 X-XSRF-TOKEN:eyJpdiI6IlZ5bHZNNlVXM0ZqM0tWd0dheUtJUEE9PSIsInZhbHVlIjoieGdyYzRtOUFHaHptMGVYbUw1ZzNIVU5hTjQ5cDM1QWljNHBWazVWZVVZdXdBRnl1YWFpc1UzVE53Q0tlbGZLQUxVazdLcWZ0enZxWG5vUURGZHVcL2RnPT0iLCJtYWMiOiI3NDIxNDJmN2Q3NWYxYWE2MTY0NDc4MGM4ZWNkMzFiNDY3OWE3ZWExMmNiMDEzZDNiYjU1Njg4NGQ5NzJhZmMxIn0=

The issue is resolved if I delete the DB session. This probably doesn't help much but I thought I would share anyway.

[tuproyecto]

Any solution?

[GrahamCampbell]

Is it working on the very latest version?

[tuproyecto]

5.1.*

[GrahamCampbell]

Please provide the exact version.

[tuproyecto]

Laravel Framework version 5.1.39 (LTS)

[nolros]

@GrahamCampbell fails in version 5.2.37 but no problem in version 5.2.38. I've run all tests and tried all scenarios and pleased to report no problem. Thank you!

[jbellomy]

Taylor merged #12059 into 5.2 which would also help reduce the read/write race condition in the 5.1 database session handler.

[trip-somers]

PROPOSAL: A try-catch for the DatabaseSessionHandler::write() method's insert attempt to watch for PDOExceptions and check PDO::errorCode() for SQLSTATE 23505 (Unique violation: 7).

If 23505, read + update. If not 23505, re-throw.

It's an extremely targeted strike, but it should narrow the race condition to the smallest possible timeframe while also avoiding an overly general approach that could cause problems elsewhere.

EDIT: It would be very similar to this solution that I found after proposing this -- #12059 (comment)

[amochohan]

I'm using separate read and write hosts on the db connection used to handle sessions, so it's entirely possible that the read server hasn't been updated with the session data written to the write server. I've never encountered replication lag (using RDS) but to eliminate this as a potential cause, I've created a new connection which has a single read/write host.

If I get no further duplicate errors in the next week or so, I'll be happy to say this is related to some sort of race condition caused by read/write replication.

[amochohan]

Unfortunately I'm still seeing this error, so I can rule out that having separate read/write connections is not the cause of this bug.

[ryzr]

Issue is still present in Laravel v5.3.26.

Currently, we have anywhere between 3 and 40 instances serving our app, with a single read/write MariaDB database. Our sessions table typically contains 15k+ sessions at a time, expiring in 2 hour intervals.

Illuminate\Database\QueryException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'fLOk3VaO0TxW1vFxrXX6q3hcGg8DmGKGpb7QsIUZ' for key 'sessions_id_unique'

Stack trace:
#0 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Database/Connection.php(725): Illuminate\Database\Connection->runQueryCallback('insert into `se...', Array, Object(Closure))
#1 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Database/Connection.php(480): Illuminate\Database\Connection->run('insert into `se...', Array, Object(Closure))
#2 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Database/Connection.php(434): Illuminate\Database\Connection->statement('insert into `se...', Array)
#3 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(2136): Illuminate\Database\Connection->insert('insert into `se...', Array)
#4 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Session/DatabaseSessionHandler.php(119): Illuminate\Database\Query\Builder->insert(Array)
#5 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Session/Store.php(263): Illuminate\Session\DatabaseSessionHandler->write('fLOk3VaO0TxW1vF...', 'a:4:{s:6:"_toke...')
#6 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(88): Illuminate\Session\Store->save()
#7 /app/xxx/current/src/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(177): Illuminate\Session\Middleware\StartSession->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response))
#8 /app/xxx/current/src/public/index.php(62): Illuminate\Foundation\Http\Kernel->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response))
#9 {main}

[taylorotwell]

There is absolutely no point in anyone else saying "I have this issue". It is very apparent people have had the issue. What is more helpful is someone working to fix the issue.

[trip-somers]

Here's another proposal since my earlier one didn't seem to gain any traction...

Instantly create/update the database record when a new session ID is generated, then proceed as normal. The idea would be to make sure there's a record (creating if necessary) when loading the session ('before' middleware) rather than waiting until storing it ('after' middleware).

[[NOTE: My previous proposal worked well for me, so I haven't spent any more time on this. Forgive me if I've spaced out or spoken incorrectly on the 'before' and 'after' parts of the session middleware.]]

[taylorotwell]

@trip-somers thanks for both suggestions. Have we actually nailed down why this is happening?

[trip-somers]

I still have no clue. Every scenario I have come up with makes no sense. It sure seems impossible that two "new" requests could exist with the same session ID. The only thing I haven't explored is the potential existence of some kind of sub/internal request/response that creates the race condition.

The theory here would be that something is happening internally that "passes" the new session ID into a subroutine that terminates (some kind of 404 or abort in template? really have no idea) in a way that triggers the DB write before the main request triggers it. This is my original "fork/branch" duplicate idea, but I still can't figure out what's forking or branching, so I don't totally buy it as possible.

Is there anything anyone (@taylorotwell, @GrahamCampbell, etc.) can think of that would spawn such a subroutine-based race condition?

Unless it more simple than that. Is it possible for the authentication cookie to have the new session ID before it is written to the database? This would fit the AJAX scenario described by some -- an on-load AJAX request with the "new" session ID terminates before main page response is completed. If so, this could be chalked up to very simple HTTP request latency / network traffic / slow connections.

[taylorotwell]

Fixed on Laravel 5.4.

[calebfavor]

@taylorotwell - Any chance you could point me to where this was patched? I am hoping to put together a fix for 4.2 as well.

**Edit: Never mind, I found it.

For those interested: d9e0a6a

[roshangautam]

Can someone please tag a release in 5.1 for this fix ?

[mediaceh]

I have same error in version 5.3.23.

[2017-02-06 11:37:18] production.ERROR: exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'XlZRvW1oqTObXyH3oI5HQi9r8HubHOoIt2eA0sJS' for key 'sessions_id_unique'' in /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91 Stack trace: #0 /var/www/html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php(91): PDOStatement->execute(NULL) #1 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php(479): Doctrine\DBAL\Driver\PDOStatement->execute() #2 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php(762): Illuminate\Database\Connection->Illuminate\Database\{closure}(Object(Illuminate\Database\MySqlConnection), 'insert into se...', Array)
#3 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php(725): Illuminate\Database\Connection->runQueryCallback('insert into se...', Array, Object(Closure)) #4 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php(480): Illuminate\Database\Connection->run('insert into se...', Array, Object(Closure))
#5 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Connection.php(434): Illuminate\Database\Connection->statement('insert into se...', Array) #6 /var/www/html/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php(2136): Illuminate\Database\Connection->insert('insert into se...', Array)
#7 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/DatabaseSessionHandler.php(119): Illuminate\Database\Query\Builder->insert(Array)
#8 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/Store.php(263): Illuminate\Session\DatabaseSessionHandler->write('XlZRvW1oqTObXyH...', 'a:4:{s:6:"_toke...')
#9 /var/www/html/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php(88): Illuminate\Session\Store->save()
#10 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php(176): Illuminate\Session\Middleware\StartSession->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response))
#11 /var/www/html/public/index.php(58): Illuminate\Foundation\Http\Kernel->terminate(Object(Illuminate\Http\Request), Object(Illuminate\Http\Response))
#12 {main}`

[roshangautam]

How wonderful, this is not patched in 5.2 branch too.

[carltondickson]

This fix isn't in release v5.1.45 but is in 5.1 branch.

How often are new tags/releases created for the LTS releases? Would second a 5.1 release/tag assuming it's good to go.

[cupit]

Hello, I'm using v5.2.45 and I noticed many problems with this, usually when the website has rush hours.. any idea how to fix it in v5.2.45?

[markwinters]

We received the integrity constraint violation on the session table yesterday. But noticed in a request that happend 38 seconds later that another error occurd stating -> General error: 1205 Lock wait timeout exceeded. This happend on the garbage collection on the session table.

When looking into this I wonder, how can the fix work? It seems to update when the insert fails. But the database already received an invalid insert in the first place. I believe this fix to be a workarround on the real issue that is not solved. It should not try to insert in the first place.

I would like to propose a solution (that was already mentioned before) to do a count request or something like that to properly check if the session already exists in the database.

[art-vanesyan]

Laravel 9
Error: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'LgM92Cl35ZxNS3b6EACA3itfgmAn77BaO91HadLf' for key 'PRIMARY'. Transaction has been restarted. Attempt 7/10. SQL: insert into sessions (payload, last_activity, user_id, ip_address, user_agent, id) values ('YToyOntzOjY6Il90b2tlbiI7czo0MDoib0M2MTVrZ2xtdjJ6WkRvelFWZGExdW9BQVkxVHc5Zk5QSXRReklGbiI7czo2OiJfZmxhc2giO2E6Mjp7czozOiJvbGQiO2E6MDp7fXM6MzoibmV3IjthOjA6e319fQ==', '1669315180', '923363', '91.211.136.202', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36', 'LgM92Cl35ZxNS3b6EACA3itfgmAn77BaO91HadLf')