Jump to content
thirty bees forum

Cookies verhindern Login im Shopsystem


Recommended Posts

Ich hatte heute einen Kunden, der sich bei mir beschwert hat, weil er sich nicht mehr im Onlineshop anmelden kann. Das geht anscheinend schon den ganzen Tag. Also habe ich das getestet und konnte mich tatsächlich auch nicht einloggen, aufgrund eines ERROR 502 - Bad gateway. Ich habe dann herausgefunden, dass es an veralteten Cookies lag. Nach dem Löschen ging wieder alles reibungslos. Allerdings wissen viele Kunden nicht wie das funktioniert und suchen sich dann einen anderen Shop, wo sie bestellen können. Gibt es eine Möglichkeit, dieses Problem zu verhindern?

Link to comment
Share on other sites

@datakick any idea why this could happen? The server is using cloudflare.

  1. I was logged in on his site. Then logged out.
  2. Now wanted to log in again.
  3. Got the 502 error.
  4. Deleted cookies.
  5. Login/Logout works without any problem.

Unfortunately I didn't test after the 502 error, if I was actually logged in or not 😞

Edit: Somehow I could get the error again. But no idea how exactly. Only worked once to recreate. Either it has something to do with checkout. There I could imagine mollie or loyalty. But both a bit unlikely. 

What I much more suspect: Could it be, that a deactivated captcha module causes it? If a module has overrides but is deactivated. Are these override still active!? I mean technically I would be surprised, if they aren't. But I have never thought about it...

Edited by wakabayashi
Link to comment
Share on other sites

This looks like issue with small nginx header buffer (if you use nginx in front of your php)

Look into your nginx error logs if you see messages like this one:

upstream sent too big header while reading response header from upstream

By default, nginx support only 4k of http headers. Sometimes it's not enough - all cookies, Location header, custom HTTP headers, etc must fit into this, which can be a lot. Especially if you have multiple cookies. For example, my PHP server returns 959 bytes in headers with single cookie. If I'm logged into back office, this would be around 2k.  

HTTP/2 200
server: nginx
date: Tue, 11 Jul 2023 06:30:39 GMT
content-type: text/html; charset=utf-8
x-powered-by: PHP/7.4.33
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
powered-by: thirty bees
set-cookie: PHPSESSID=5ng3b7o88aktkk43uktrvnb645; path=/
set-cookie: thirtybees-52c547b202be54b989b7b16314b81de3=def5020083e391b99d2b735eec52301c2b655e1aa64110a7382a792b9e548322f81599d1c6480e39ee0f24a9ea1cf5ddfc502241d446f14065f449cae12783db1ad8db942d281e8dcabb67239a3d8592c77b8da9a5294caf3af5a8c974eccb9b8609801ebb9809971eef3f56eff88cd3c639d8150b737a21e13ac9507afd57ea3b67cfe39a89edda5f125ce2b0ff7c1bb617efee261f71f4df37f3a412be793c9d025d90b5439e0d90a0cd6409eb3d8d420ce601d72e682ba9578e7f451015be1be55afd7259a70f5db9a10e9e068cb418315637648413fada4e12c4; expires=Mon, 31-Jul-2023 06:30:38 GMT; Max-Age=1727999; path=/; domain=***.com; secure; HttpOnly
x-powered-by: PleskLin

If you use modules that creates their own cookies, this can easily reach 4k limit. If that happens, nginx will then drop the response from PHP, and returns 502 error page instead.

The fix is to modify nginx configuration and increase buffer size. For example, I use this:

        fastcgi_buffers 8 64k;
        fastcgi_buffer_size 64k;

 

Link to comment
Share on other sites

Thanks for the quick help!

As far as I can see I have 3 options regarding PHP in my server settings:
1. FastCGI Application (Apache)
2. FPM Application (Apache)
3. FPM application (nginx)

Option #2 is selected for me. So I would assume I don't have nginx. I couldn't find any other settings for it either.

Link to comment
Share on other sites

  • 3 weeks later...
15959#0: *1869971 upstream sent too big header while reading response header from upstream

Found now this in the logs. Which clearly indicates, that you were right @datakick.

What confuses me a lot: he has apache selected, so why is there a nginx error?

I contacted the webhoster. As it is shared, they refuse to increase any values. Is this normal? Does it mean, that thirtybees and shared webhosting is not really an option? I mean personally I have a dedicated server for multiple reasons, but I always thought, that it's possible to use shared hostings as well. What is your experience with this? Is  this hoster total shitty or is it kind of normal to get problems with it?

I noted, that it's not so easy to go the next step after shared webhosting. Let's say you pay 2-15$ for shared and often 80$ or more for private managed server. An unmanaged server is no option for 99% of merchants. I see a lot of vps/cloud stuff, but often this is not managed as well. Am I missing something or is it not so easy to get something managed for 35$, that is better than shared webhosting offers?

Edited by wakabayashi
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...