Put guardrails on 'xf_error_log'

[frm]

It appears there was an error that continued due to continuous traffic pounding that task, taking the server offline.


There should be no reason the error log can run rampant to about 2 million errors at a storage cost of 29.2 GB.

If, say, an attacker learned of what could cause an error, they could pound the site until the server (affecting other sites) goes down.
It would be okay if XenForo could be able to Clear the log within the ACP, but at this size, it requires a direct query to resolve, as XenForo runs into trouble clearing it via the ACP (i.e., see console).

TRUNCATE TABLE xf_error_log;

Surely, there could be a row limiter, and if it exceeds that, perhaps (1) email every X hours until it's resolved?

 

[briansol]

defining thresholds for this could be tricky. It could be a first in, first out concept. After 100,000 rows, row 1 goes away and row 100,001 gets added.

 

[frm]

defining thresholds for this could be tricky. It could be a first in, first out concept. After 100,000 rows, row 1 goes away and row 100,001 gets added.

I'd be fine with a cap and FIFO system as it'd probably be easier than emailing the admin.

As is, this would make novice self-hosted admins ante up to get fixed as you cannot get into control panels without free disk space.

I wonder if XF Cloud is vulnerable to something like this happening? (Probably not possible with 400,000 monthly page views, unless the admin never fixes the error or Clears the log before it's too big to run in ACP)