Infamous "Security Error" while trying to save add-on settings

Freelancer

Well-known member
I have one add-on where I can not save any changed options in the ACP. If I just hit "save" without changing anything it does not generate an error. If I change a setting and hit save this error occurs:
Code:
Error:
Security error occurred. Please press back, refresh the page, and try again.

Where shall I look to narrow down the root of it?
 
This isn't a xenforo bug (should be posted in developers area)

What does the error say in the server error logs, if there are any:
admin.php?logs/server-error

but sounds more like a permissions error (logged out / timed out / switched user)

see:
https://xenforo.com/community/threa...ss-back-refresh-the-page-and-try-again.25839/

https://xenforo.com/community/threa...ss-back-refresh-the-page-and-try-again.18169/

Saving options is a XF CORE function. So it's not an add-on bug.

No, I can exclude any failed login or something like that. This error is persistent and all other saving options operations work without problems.
 
Certainly doesn't have to be a bug in XF or the add-on specifically, so there's certainly no finger pointing going on, just for the record.

Though the nature of it only happening in a specific add-on could be relevant. Does the add-on have a considerable number of options? It could be hitting certain limits in PHP. post_max_size seems unlikely in this case, but max_input_vars could be a factor.

If you check php.ini or phpinfo, what is your max_input_vars set to?
 
Those seem fairly reasonable; certainly the default for max_input_vars is 1000 so that seems ok.

Does it behave the same in another browser? Or in your current browser with all extensions disabled?

It's worth noting that there are other server side factors that can essentially override the ma_input_vars value. Suhosin can be an example of that. I think it has a "suhosin.post.max_vars" configuration. This could be lower than the value set in php.ini. Do you have anything like that (or similar to it) on the server?
 
I tested it with all add-ons deactivated and it still occurs, as well as with a different browser. I have no clue if Suhosin is installed, I hear this for the first time. I am with a shared server hosting provider. Shall I contact them and what shall I ask them or better where to point them?
 
I suppose it's possible it could be hitting max input vars, so it might be worth upping it to 2000. Even for an add-on with a lot of options, that seems like a big number to hit. Though certain individual options may actually be more than a single input. For example, each individual checkbox is an input, each individual radio button is an input. Each option itself has a hidden option which is used internally. So even if you had 500 text inputs, that would actually hit the 1000 limit. Significantly if there's any options that work in a similar way to the "Censor words" option, each censored word takes up 2 inputs plus a third for the hidden value. So, worth a try, at least.

Key things to ask your host would be
  • Can they increase max_input_vars for you (if you can't do it yourself)
  • Do they have suhosin installed? If so, what is the value of suhosin.post.max_vars and can it be increased (probably up to 2000)
  • Is there anything else either in the web server itself, PHP or an extension, that might be limiting the number of allowed inputs to be submitted in a POST request?
There might be a way to identify exactly how many inputs are being submitted from this page. If you're somewhat familiar with your browser's developer console (usually accessible with F12) there is usually a "Console" tab. You should be able to enter jQuery code in this.

Code:
$('#content .xenForm.formOverlay').find('input').length

That command (run on the add-on options page) should return a number, and that number is the number of inputs which are being submitted. For a default XFMG install it's 220! It'd still take some going to hit 1,000 but certainly worth eliminating that possibility.
 
Key things to ask your host would be
  • Can they increase max_input_vars for you (if you can't do it yourself)
  • Do they have suhosin installed? If so, what is the value of suhosin.post.max_vars and can it be increased (probably up to 2000)
  • Is there anything else either in the web server itself, PHP or an extension, that might be limiting the number of allowed inputs to be submitted in a POST request?
I will send in a support ticket to them.

$('#content .xenForm.formOverlay').find('input').length
Um... I am not sure what this means... but both in Safari and Firefox console the return is "0"...?
Bildschirmfoto 2017-02-17 um 16.37.59.webp
 
There might be a way to identify exactly how many inputs are being submitted from this page. If you're somewhat familiar with your browser's developer console (usually accessible with F12) there is usually a "Console" tab. You should be able to enter jQuery code in this.

Code:
$('#content .xenForm.formOverlay').find('input').length
That command (run on the add-on options page) should return a number, and that number is the number of inputs which are being submitted. For a default XFMG install it's 220! It'd still take some going to hit 1,000 but certainly worth eliminating that possibility.
AMS (Articles CMS) = 868
Showcase = 701
UBS (Blogs) = 661

He is able to save AMS and UBS options just fine. It only throws it while saving SC options. I currently just have things in one option group with a tabbed layout similar to XFMG. Probably should move to several option groups.
 
Certainly could prove that it's not related to the input vars thing, then. Though the test isn't totally scientific. Some of the inputs might not be sent to the server, for example if they're disabled, and this won't account for that. Still, there's likely a huge difference there so seems unlikely after all.

I still think there's something server side blocking it. For reference, the security error generally means that the _xfToken value was either invalid, missing or it has expired. It could certainly be missing if something was stripping it out (such as when the input limit was reached).

There's similar variables that could impact it, depending on the web server. Nginx has client_max_size_body and LiteSpeed has a way to limit the request body, IIRC. If there are any options that can contain a lot of data, such as textarea elements (actually they won't be counted in the input check I mentioned earlier, though I guess you haven't got 150+ of them :p) or similar then it's possible the total request size could be too high and it is therefore getting truncated (which would strip off the _xfToken value).

I am certainly intrigued. We really ought to see what the host says, I guess...

One thing that might shed some light though (and just discount it being some weird invalid value for some reason) is if you are happy editing a PHP file, you could edit library/XenForo/Controller.php and find:

PHP:
new XenForo_Phrase($isAjax ? 'security_error_occurred_ajax' : 'security_error_occurred')

And replace it with:

PHP:
new XenForo_Phrase($isAjax ? 'security_error_occurred_ajax' : 'security_error_occurred') . ' (' . $csrfAttempt . ')'

The $csrfAttempt variable here should have the actual reason we detected to fail the verification.

So the error you will receive when you try again is something like:
Code:
Error:
Security error occurred. Please press back, refresh the page, and try again. (missing)
 
I know WHY I am with this hosting provider... They already answered!
  • They are NOT using Suhosin
  • They did change the max_input_vars to 3000
I tested it in this minute and .... IT WORKS NOW.... :eek:

Well, the price you pay for demanding Admins that want option, options, options... :p

Thanks @Chris D and @Bob
 
Last edited:
That's certainly an interesting development seeing as it was already set to 1,000. There are other things that may count as an input which are part of the request, but it's still somewhat confusing that there appears to be more options in one add-on and they saved fine... Well, at least it's sorted :)
 
One hint could be that the options include the Showcase Categories in Listings (Slider, Blocks etc) and that I do have DOUBLE the categories in Showcase than I have in AMS...
I was just mentioning this to Chris as a possible reason why SC wasn't saving, but AMS was. At any rate, I'll be breaking options out into several options groups moving forward.
 
Top Bottom