Fabrik 3.8 puts Joomla 3.6.4 in timeout when saving / closing some fields definitions [ RESOLVED ]

[smalldragoon]

Hello,
Configuring Fabrik, I have from time to time a complete freeze of my website when I save or close some pages from Fabirk ( site is timing out after that during 20/25 min ).
Anyone would have some insights ?
Of course, I checked creating new articles, menus etc... and no issues, it only applies when I use Fabrik
Thanks !

 

[Bauer]

Have you thought of trying a newer version of Joomla - v.3.6.4 is from Oct 2016. The latest Joomla v3.8.5 seems to work fine with Fabrik 3.8.

 

[smalldragoon]

Hi,
Updated joomla to 3.8.5... still same issue
Will repost in standard support ....

 

[cheesegrits]

See your other thread about the CDD.

It seems to be your host has some overly aggressive policies - either resource usage (like page loads per second) or security (some mod_security rule) which doesn't like the series of AJAX calls we are firing off in things like backend option setting.

While I was working on your site, it happened to me. I fired up my VPN to pick up a new IP, and got straight back in.

You need to talk to your host, and find out exactly what is triggering the block. They should have logs.

This is something very site / host specific, otherwise we'd be seeing everyone runnign into the problem.

-- hugh

 

[prophoto]

I've also seen this with some security plugins that create a 'firewall' to protect Joomla.

 

[smalldragoon]

HI ,
Thanks a lot, I created a ticket without any answer so far, but so I wanted to keep you up to date.
I will post the final status for others to know
Thanks

 

[Sophist]

Let us suppose that there is a firewall or similar which is "causing" this. These firewall would presumably be responding to a request from the browser when the user closes the window. Does Fabrik have any "on close" events that run ajax?

So, a few things I think might be worth trying to diagnose the issue further:

It seems to me that the first thing we need to determine is whether it is just the browser which is hanging or whether the browser is waiting for a server response or whether there is some sort of continual request / response traffic between the browser and the server.

When you close a window and "it hangs", what exactly is hanging? Is it the browser tab / window, the entire browser, the entire client system? Is there significant CPU% being used by the Browser during this period? And what is the name of the process that is using the CPU? Do the webserver logs show your browser sending in a request? If so what is the URL, and what happens if you manually enter that URL into your browser when it isn't hung?

When it is "hung" is the server accessible form a different browser on the same machine or a different browser on another client?

Do we have any idea why the timeout appears to be 20/25 minutes (which is a VERY long timeout)?

 

[cheesegrits]

It doesn't do it when "closing" a window, it was doing it to me in the middle of working on the backend, where AJAX calls would suddenly start failing, and my IP was completely blocked. The browser isn't "hanging" and the server isn't "stuck", it's just the IP gets blocked for about 30 mins, which is a standard temp block time. I was able to get straight back in with a VPN IP ... until that one would get blocked again after working on the backend for a while.

My bet is that there's a mod_security (or similar) rule that is enforcing connection rates. The Fabrik backend does a lot of rapid fire AJAX calls, as can forms on the front end, and I've seen this situation before, where an overly aggressive mod_security (or some application firewall) has an "X connections per Y unit of time" limit, to catch DDOS attacks or brute force attacks (or just because it's a cheap ass shared server enforcing usage restrictions), and temp blocks the IP. So a backend edit page (like editing a form) that fires off a bunch of AJAX calls to load plugin params, table/field dropdowns, etc, and triggers the block.

-- hugh

 

[Sophist]

Hugh: Whilst your explanation sounds plausible, I would hope that Ajax requests would take advantage of HTTP 1.1 persistent connections.

I have taken a look at the Ajax request/response headers for back-end editing of an element with 2 validation plugins. This issued 2 requests for require.js (one after first page load and one from ace editor, both of which were satisfied from the browser cache) and 2 for each validation rule i.e. 4 in total.

The validation ajax were issued sequentially (though it would have been better for performance if they had been issued in two lots of two in parallel) and all contained "Connection:keep-alive" in both request and response headers. My server is also sending a "Keep-Alive: timeout=15" response header.

Based on this I would hope that the Ajax requests are reusing the same connections.

That said, a front-end form with multiple simultaneous ajax validations would almost certainly do more in parallel, and would require 1 simultaneous connection for each parallel ajax validation. If the user then waits (say) 30s before submitting another round of validations, and the server has a 15s keep-alive timeout, then it would make another set of parallel connections. (But is this really any different to loading a page with several simultaneous connections to download js, css and graphic files? Answer: Probably not from a connections perspective, but definitely from a simultaneous php perspective since js, css and graphics files will usually download direct without running php - so a security monitor concerned about heavy php loading from a single user might get triggered.)

All that said, this sort of behaviour is increasingly common these days in web-based applications - so security setting should be taking this into account.

Bottom line: Determining what is triggering the "firewall" blocking for 30m is not so easy to determine, and the best bet would be to ask your hosting provider whether it is their infrastructure which is triggering a block.

 

[smalldragoon]

Hi sophist, posted in 2 different forums.. so final answer is : there was indeed a "bot" which was blocking for 1 hour my IP when he assume there was a "brute force" attack ...
I'm chaging hoster for my website ....

 

[Sophist]

Perhaps we should implement Mootools Request.Queue for the front end validations - this allows you to limit the number of parallel ajax requests sent to the host to a defined number which we can put into a global fabrik setting.

But I am glad we have identified the cause.

 

[smalldragoon]

Hi Sophist
could be a good idea for others maybe yes.
It was not a big deal for me to switch Hoster as it is a small website but when you have more constraints, I guess switching could be much more problematic.
For reference for you & others who will find this thread : OVH is the problematic one and LWS works straight forward without any additional configuration than the standard joomla settings to activate/deactivate in php.ini ...