Dolibarr: Unset POST by CSRF protection in main.inc.php (POST for this token was already done or was done by a not allowed web page with a wrong token).

[homer8173]

Instructions

everywhere dolibarr keep saying this to the users

Bug

Unset POST by CSRF protection in main.inc.php (POST for this token was already done or was done by a not allowed web page with a wrong token).

Environment

• Version: 11

Expected and actual behavior

dolibarr must be user friendly or it's his future wich is compromised
i already seen open sources die for less than that

Steps to reproduce the behavior

wait on a page, open two pages, use history etc

Attached files

We can't leave this like this, normal humans doesn't understand what we are talking about and doesn't want to lost their history usage, they want to have their pages open for hours.

Example :

BOB take a coffee, he comes back to Dolibarr, he fulfils a form and on validate he losts all his content ??????????

For sure BOB will complain about Dolibarr and most of users will. We can't leave this like that.

We are ready to help finish this security feature. Who wants to talk about ?

[eldy]

Problem here is not on delay but on the fact that you open other page and the feature to protect by token is still in development and is not yet finished. When development will be finished, this will not happen.
Until the development is not finished, you should not use this experimental feature of the hidden constant MAIN_SECURITY_CSRF_WITH_TOKEN=1 on production that is a "still in development option". May be for v12

[homer8173]

OH sorry, i haven't seen it waas due to the activation of experimental features.
I thought it was native in Dolibarr 11 and i was worried

[eldy]

Another explanation is that there is an external module that load a php file in background (for example a link to a css.php of js.php file or an ajax call) and the file does not include the line:

if (! defined('NOTOKENRENEWAL')) define('NOTOKENRENEWAL', '1'); // Disables token renewal

If this is the case, this may trigger this error even with "stable" level. But in such a case, it means the module is not compatible with v11 and +

[altatof]

thanks @eldy for the explanation; so i have to modify all my modules to add this in css.php, js.php and ajax called scripts ? (i did not find this in Changelog)

[dolibit-ut]

Hello, i have the same problem with one installation.
This is a Dolibarr linux installation by a webhosting provider
and use a package from Installatron -> (https://installatron.com/dolibarr?s=4825da1916f3e6811f20c7f8d3d3a3ab)

So i did an update from Dolibarr 9.0.4 to 11.0.2 and now got the message

Unset POST by CSRF protection in main.inc.php (POST for this token was already done or was done by a not allowed web page with a wrong token).

But there is no 'hidden config' entry with CSRF - or not shown
and I can not edit anything anymore in Dolibarr.
If I try to add a MAIN_SECURITY_CSRF_WITH_TOKEN = 0
I get the same warning

Can I overwrite this in config.php or so?

Otherwise I have look for a direct database access to edit in llx_c_const?

[dolibit-ut]

We have now access to the database and I checked the llx_const table and there was no
MAIN_SECURITY_CSRF_WITH_TOKEN entry.
Then I insert the record MAIN_SECURITY_CSRF_WITH_TOKEN = 0 and the CSRF warning was over
and we can use this Dolibarr installation again.

Comment:
After the CSRF Token warning was over - came the message, that the module DebugBar exists
twice.
In this installation was an 'old' module DebugBar active in custom - and now it is part of the standard installation.

Could this possibly have been a reason for the CSRF warning?

[altatof]

i guess that security token is activate by default in v11 and that you can desactivate it with the hidden constant.

[eldy]

thanks @eldy for the explanation; so i have to modify all my modules to add this in css.php, js.php and ajax called scripts ? (i did not find this in Changelog)

Yes you have to.
For the moment, the protection works only when you are using dolibarr with MAIN_FEATURES_LEVEL >= 2 (so when your dolibarr is set to be in "develop" mode). So developers can find problems and solve them. So it is a transitional test not yet enabled by default (but it will one day), this is the reason why it is not visible in ChangeLog.
This need to secure modules was just announced during the 2 latest devcamp, but for the moment, if it is not done, it should have no effect (except if MAIN_FEATURES_LEVEL >= 2 and version is >= 11, both conditions are required to trigger this error).
To prevent this even in develop mode and be ready for feature, this is what to do:

Forms must add the field
print '<input type="hidden" name="token" value="'.newToken().'">';

And Ajax and css pages must add the constant
if (! defined('NOTOKENRENEWAL')) define('NOTOKENRENEWAL', '1');

[dolibit-ut]

Yes, the installation was in MAIN_FEATURES_LEVEL 2.

Is it possible to check this before Dolibarr update run to give a warning
or change the Feature Level with Dolibarr update with a message that it was changed to protect for run in this situation?