Something with cookies after updates

[Kofod95]

Problem: Some customers go to the log-in, enter their email and password, after which they are redirected to the homepage without being logged in. If they repeat, the same happens.
Conditions: Unknown. It happens for only some customers and I have been unable to make it happen to myself. It happens on two shops on 1.0.8.20: both of which have data from older versions (1.0.4.0 and 1.0.7.12 - but even older, as they were originally built on OSC in 2012).
Solution: The best I've come up with, is a warning on log-in, that suggest one clears cookies, if they are having trouble with the log-in, as clearing cookies solves the issue. What would be the right way to do it?

//Daniel

[burt]

This used to happen frequently when the settings in configure.php were not quite correct.

In addition try forcing cookie use in the admin area -> config (I don't recall where the setting is exactly, you'll find it)

[ecartz]

Have you tried having them log out?

Yes, I realize that you want them to log in. But if the problem is bad cookies, log out should clear the cookie.

If you can talk to any of the affected customers, you might try walking them through looking at their cookies. On Firefox, that would be right click > Inspect > Storage tab (may be under >>) > Cookies

If you want to try manually clearing cookies, something like

Code: Select all

$options = COOKIE_OPTIONS;
$options['expires'] = strtotime('1 day ago');
foreach (array_keys($_COOKIE) as $cookie) {
  unset($_COOKIE[$cookie]);
  setcookie($cookie, '', $options);
}

You could try that in a hook that runs before the login processing does.

[Kofod95]

Thank you both very much for your suggestions! I was at a loss, but now I have something to pursue.

This used to happen frequently when the settings in configure.php were not quite correct.

I will have a look to make sure I didn't mess anything up there and compare the old configure.php settings with what I have now.

In addition try forcing cookie use in the admin area -> config (I don't recall where the setting is exactly, you'll find it)

I have it at false (for reference: admin->configuration->sessions), which it also used to be. I have never tried changing anything there, as I really don't understand what it would do
I suppose forcing cookies would mean just that: that the session will be stored in a cookie and not in the db? Any drawbacks?

Have you tried having them log out?

Yes, I realize that you want them to log in. But if the problem is bad cookies, log out should clear the cookie.

Sending a link to logoff.php and have them follow that? I haven't tried that, but will make sure to try that next time, thank you!

If you can talk to any of the affected customers, you might try walking them through looking at their cookies. On Firefox, that would be right click > Inspect > Storage tab (may be under >>) > Cookies

Would it be beneficial for you to have the data? In that case, I will gladly try to walk someone through that, and potentially email me the cookie. If you don't care, I might just go for:

If you want to try manually clearing cookies, something like

Code: Select all

$options = COOKIE_OPTIONS;
$options['expires'] = strtotime('1 day ago');
foreach (array_keys($_COOKIE) as $cookie) {
  unset($_COOKIE[$cookie]);
  setcookie($cookie, '', $options);
}

You could try that in a hook that runs before the login processing does.

Just out of curiosity: is it possible that the new cookie class has something to do with the "error", or is it simply my stupidity (or just lack of knowledge / carelessness)? We did not have this problem when the stores were updated from OSC 2.3.4 to Phoenix 1.0.4.0 or from OSC 2.2 to Phoenix 1.0.7.12, but I may have been more careful with things then, because I was aware that I was stupid

//Daniel

[ecartz]

Would it be beneficial for you to have the data?

This is still in the realm of trying to understand what is happening. You mention that you can't replicate the issue. This is a troubleshooting step that might indicate

1. That configure.php is wrong.
2. That they (the users) are doing something weird.
3. That I flubbed something in the new Cookie class.
4. That the browser/PHP flubbed something that we'll have to try to hack around.

It's possible that we might see how to replicate the problem from what their cookie information says.

[14Steve14]

Problem: Some customers go to the log-in, enter their email and password, after which they are redirected to the homepage without being logged in. If they repeat, the same happens.
Conditions: Unknown. It happens for only some customers and I have been unable to make it happen to myself. It happens on two shops on 1.0.8.20: both of which have data from older versions (1.0.4.0 and 1.0.7.12 - but even older, as they were originally built on OSC in 2012).
Solution: The best I've come up with, is a warning on log-in, that suggest one clears cookies, if they are having trouble with the log-in, as clearing cookies solves the issue. What would be the right way to do it?

//Daniel

We are having the same problem, which we cannot replicate.
See posts here. viewtopic.php?f=28&t=2669
Customers cannot login or even change their password using the store system as it entails a login. Customers are saying they are using saved login information from their device and know that the information is correct. We have tried updating a customers password and even though we can login using that information, they cant.

If a customer contacts us by phone we are trying to get as much information as we can, but it is hard trying to get our customers to understand what a cookie is. What we have found is that this is mainly happening to customers who have not visited the site since our last update nearly a year ago now. We upgraded from 1.0.7.11 to 1.0.8.21 then to 1.0.9.0 using old store data but brand new files from 1.0.8.21.

If the customer uses a browser that has not been used to access out website then it all works fine. As a quick test to see if it is the cookie problem we are asking the customers to open the website in a new private/incognito window in their browsers. That should open the site using no stored files or cookies. In every case so far this has worked, so we then recommend clearing tier cache and any saved files for our website.

[ecartz]

We have tried updating a customer's password and even though we can log in using that information, they can't.

This suggests that changing the password (which they should be able to do with the "Forgot Password" link) wouldn't help.

If it's a bad cookie, possibly one that preexisted the upgrade to PHP 7.3, then the best solution would be either to always clear cookies before logging someone in, to clear cookies on login failure, or to provide a button to clear cookies.

PHP changed how they did cookies with PHP 7.3. The Cookie class is really two classes. One for PHP 7.2 and under; one for PHP 7.3+ It's possible that those are incompatible.

I gave Daniel some code to clear cookies. I don't know if he is using it or not.

If not, wrapping that code into a hook is the kind of thing that Burt does for beer money.

And of course, you could always work with a certified developer.

There may be a core solution, but I don't want to modify core until we know that a solution works.

[14Steve14]

@ecartz You could be on to something with the php versions. Our old site was on php7.2 whilst the new site is on php8.0. I will investigate you code suggestion further.

[Kofod95]

No, sorry I never gave any further replies here. Since the last post I made in this thread, I've been waiting for someone new to call in and report the problem, so I could have them send me the cookie-contents. I had added a banner, saying some were experiencing problems, explaining how to solve it (to make sure not to lose customers outside opening hours) and encouraging people to call, if they had the problem, without clearing cookies first.

Since no one called, I removed the banner after six months, and hooked the code to remove cookies given by ecartz in just to make sure.

//Daniel

[14Steve14]

Since no one called, I removed the banner after six months, and hooked the code to remove cookies given by ecartz in just to make sure.

//Daniel

Hi Daniel

Would you share the hook you used

Steve