Cookies causing too many redirects issue?

[benw]

Hello.

 

We are getting a problem on our Prestashop 1.6 shop where people are randomly experiencing a too many redirects error (lots of 302s to the root /) which makes the whole website inaccessible. This is only happening on our staging server, it doesn't happen on our local environments. The only way to fix it is to delete a cookie which is created at the time of the error. We have tried debugging the contents of this seemingly dodgy cookie, but can't see anything that is stored in it that would cause a redirect issue. 

 

We have tried many different things in trying to fix this to no avail:

• Various .htaccess fixes including regenerating it
• Disabled the Advanced SEO Friendly URLs module we are using to clean the URLs - https://addons.prestashop.com/en/url-redirects/19643-advanced-seo-friendly-urls.html
• Tried across a number of browsers, happens in all of them
• Played around with the various cookie settings including changing the Cookie IP check but this made no difference

It can happen 5 times in 10 minutes or you can go days without having the issue. There doesn't seem to be anyway to reliably replicate it. It is also worth noting that we are using PHP7 with the custom Blowfish class.

 

Our current server setup:

Prestashop 1.6.1.16

6 core CPU with 8GB RAM

CENTOS 7.3

Apache 2.4.27

MySQL 5.6.37

PHP 7.0.23

 

Thanks

 

 

 

 

 

[abennen]

I have exact the same issue!

[abennen]

I've found this answer in another topic and it works for me:

1.- Login as Administrator in Prestashop and enable "SSL" and enable "SSL on all pages" options. Both are under Configure -> Shop Parameters -> General.

 

 

[benw]

We aren't using an SSL on our staging server at the moment, though the live site will obviously have one. We weren't planning on adding one to our staging server, though I guess there is no harm in adding a self-signed certificate and enabling these options to see if it works.

[benw]

We installed a self signed certificate on our staging server and that doesn't seem to have had an effect as someone in our office has had the redirect issue again.

 

Anyone else have any ideas?

[Scully]

I cannot confirm this issues occurding with PS 1.6.1.15 nor PS 1.6.1.17. I would guess there are some non default modules running causing these issues.

Reading out the webservers logfiles (both access and error log) could help to find more information.

I also would recommend to disable non-default modules one-by-one for testing purposes.

[benw]

We originally thought this was limited purely to admin users as it only happened when you had been logged into the admin. It has now happened to one of my colleagues who has never logged into the admin, only the front end. This is pretty alarming now, as the site is due to go live soon and we can't have this happening to customers!

 

There is nothing of use in the access and error logs, only hundreds of 302s to the site root (/). There were a load of references to our local development domain in the various connections tables so have emptied those to see if that helps. It's pretty difficult to debug as we haven't found a reliable way to replicate it!

[benw]

I think we've found the problem.

 

It seems to be caused by Apache mod_security.

 

In WHM ModSecurity Tools, there are a lot of 302 errors shown e.g.

 

Request:

GET /

Action Description:

Access denied with redirection to http://www.example.com/ using status 302 (phase 4).

Justification:

Pattern match "^5\\d{2}$" at RESPONSE_STATUS.

 

 

 

 

 

 

Request:

GET /

Action Description:

Warning.

Justification:

Operator GE matched 0 at TX:outbound_anomaly_score.

 

We managed to fix it by editing ModSecurity Vendors - disabling "OWASP ModSecurity Core Rule Set" and enabling "OWASP ModSecurity Core Rule Set V3.0" instead.

[patrizia.vergassola]

On 9/20/2017 at 11:15 AM, benw said:

I think we've found the problem.

 

It seems to be caused by Apache mod_security.

 

In WHM ModSecurity Tools, there are a lot of 302 errors shown e.g.

 

Request:

GET /

Action Description:

Access denied with redirection to http://www.example.com/ using status 302 (phase 4).

Justification:

Pattern match "^5\\d{2}$" at RESPONSE_STATUS.

 

 

 

 

 

 

Request:

GET /

Action Description:

Warning.

Justification:

Operator GE matched 0 at TX:outbound_anomaly_score.

 

We managed to fix it by editing ModSecurity Vendors - disabling "OWASP ModSecurity Core Rule Set" and enabling "OWASP ModSecurity Core Rule Set V3.0" instead.

 

It happens to me also with OWASP ModSecurity Core Rule Set V3.0 enabled...any help?