Jump to content

Recommended Posts

Hi,

 

We've been working on a clients prestashop which was recently upgraded to 1.5

 

Throughout the new site they've been sporadically getting issues where their cookies seem to get corrupted, which causes the cart to be lost.

 

The cart getting lost wouldn't be so much of an issue if it weren't for the fact that once the cookies seem to get corrupted (and I use corrupted loosely, I haven't a clue what precisely is happening to them at the moment) it persists, and until they delete all their store cookies, it flat out won't be able to write any new data in the cookie, disabling all form of logging in or cart storage.

 

We've been tracking it down and debugging it for a few weeks now, and it's got to the stage where I can track exactly when the issue happens, but unfortunately it's just become even stranger.

 

It attempts to write a seemingly basic cookie, nothing wrong with the string I can see

 

date_add|2013-10-15 01:18:16¤id_lang|1¤id_currency|3¤country_code|17¤id_guest|613051¤id_connections|152010¤last_visited_category|23¤id_cart|27740¤checksum|3418797989

 

We've got logging tracking every single cookie creation call, so that's a copy of the pre-encrypted data. However, the next write call to the cookie reveals that this is what's stored inside it:

 

date_add|2013-10-22 12:32:16¤id_lang|1¤id_currency|3¤country_code|17¤checksum|830195806

 

Which is rather strange really.. firstly because that cookie is logged as being created at 12:15:13.. so where that particular datetime came from is a bit of a worry.

Secondly, because nowhere at any point does the database log that particular bit of data as being stored.

 

At any point past that, it's able to read the cookie in, but is completely unable to write to it, and it remains that way currently on the clients machine a day after. From that point, any cookie attempt is generally along the lines of:

 

date_add|2013-10-22 12:32:16¤id_lang|1¤id_currency|3¤country_code|17¤id_guest|635219¤id_connections|152013¤checksum|4035921796

 

Where it keeps attempting to create new guest accounts and assign them to the cookie

 

Another oddity is that I set up a second duplicate cookie to see whether it was random or not. Both cookies got set to the same value and both remain unwritable, so possibly either it's something about that particular entry of data, or there's some form of hidden call being made to setcookie, bypassing the standard Cookie class. I've done a search for that, but not found any

 

I dont believe it to be related to the SSL, as the problem remains whether on the normal or secure pages, as soon as any product is added, the basket just remains empty after a page refresh.

I also tried a few variants of changing the various cookie settings with regards to the domain/ssl, and none made any appreciable difference at the time

 

The store is using multistore setup, but I've been tracking that alongside it and the problem didn't occur during a multistore switch, they remained on the same shop the entire process.

 

I'm frankly a bit stumped as to what might be causing it, and am hoping anyone else might have encountered something vaguely similar and have any other ideas to look into

Link to comment
Share on other sites

Took weeks, but finally tracked it down at least. Not sure what caused the original issue, but it was an interaction with the multishops and the ssl_domains.

 

The main store, on www. was matched with the ssl domain, so never sent over the domains array for comparison when constructing a new cookie. It's cookies all got stored as www.store.com

 

The other multistores were running through subdomains with different ssl paths. These ran through the comparison and stored cookies on: .store.com

 

Still no clue how it happened, but the client had somehow managed to get the main shop to store a cookie on .store.com. There were then two cookies with the same name, one www., one root.. I believe that when writing a cookie, it would automatically write it to the first found cookie, but when reading, the first would end up getting overwritten by the second, leading to the total breakdown of the cart

 

The fix we used was to disable the check to see if the domain and ssl matched, forcing it to always store the cookies on .store.com, but this might not work for everyone depending on their particular multishop setup.

Putting on the fix itself however caused the issue to happen to anyone who had the old cookies stored, necessitating a bit of an ugly hack where we had to just force it to remove any cookies set to www.

 

Thought I'd give some pointers as to where to look if anyone thinks they're having a similar issue

Link to comment
Share on other sites

×
×
  • Create New...