CSRF token error while filtering timesheets by status about dolibarr_project_timesheet

[vidlb]

If I set MAIN_SECURITY_CSRF_WITH_TOKEN=0, it fails with the following message :

This website or feature is currently temporarly not available or failed after a technical error.
This may be due to a maintenance operation. Current status of operation (2023-02-01T17:12:46Z) are on next line...
Dolibarr a détecté une erreur technique. Vous pouvez lire le fichier log ou définir l'option $dolibarr_main_prod sur '0' dans votre fichier de configuration pour obtenir plus d'informations.

[vidlb]

@delcroip do you have any clue of what could be the source of this problem ? Could you please tell me if there is any log / configuration file I can post here to help with this issue ?

[delcroip]

It seems an ( is missing

[vidlb]

I would be happy to help / contribute but I don't know PHP really well. SQL I can do.
I just tried to find which file is used to generate this query.

Doing a simple search in the repo using part of the failing query does not help.

[vidlb]

So you can confirm the CRSF token error may be due that SQL typo ?
If so the error message is misleading.

[delcroip]

should be fixed with 4.6.2, reopen issue if not

[vidlb]

Hi @delcroip , I don't see the reopen button.
The SQL error is gone, but the CRSF token error is still here a described in this issue.
Message in the log file :
2023-03-17 09:17:30 WARNING 193.48.189.250 --- Access to POST /custom/timesheet/TimesheetUserTasksAdmin.php refused by CSRF protection (POST method or GET with a sensible value for 'action' parameter) in main.inc.php. Token not provided.

If deactivated, another error appears as described here.

In that case there is another SQL error in the logs :

2023-03-17 09:20:18 ERR     193.48.189.250  DoliDBPgsql::query SQL Error query: SELECT t.rowid,  t.fk_userid,  t.date_start,  t.date_end,  t.status FROM llx_project_task_timesheet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%3%') LIMIT 26
2023-03-17 09:20:18 ERR     193.48.189.250  DoliDBPgsql::query SQL Error message: ERROR:  42883: operator does not exist: integer ~~* unknown
LINE 1: ...eet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%3%...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
LOCATION:  op_error, parse_oper.c:722 (DB_ERROR_42883)
2023-03-17 09:20:18 ERR     193.48.189.250  DoliDBPgsql::query SQL Error usesavepoint = 0
2023-03-17 09:20:18 ERR     193.48.189.250  Error url=/custom/timesheet/TimesheetUserTasksAdmin.php, query_string=, sql=SELECT t.rowid,  t.fk_userid,  t.date_start,  t.date_end,  t.status FROM llx_project_task_timesheet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%3%') LIMIT 26, db_error=ERROR:  42883: operator does not exist: integer ~~* unknown
LINE 1: ...eet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%3%...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
LOCATION:  op_error, parse_oper.c:722

[delcroip]

Can you paste the url on which you have the error message, i couldn't find it.

Br

[vidlb]

It's /custom/timesheet/TimesheetUserTasksAdmin.php

[delcroip]

I mean in the browser, I tried to update all actions but I must have missed one

[vidlb]

Not sure what you mean but here is the complete url after I click on the admin section :
https://dolibarr.mydomain.fr/custom/timesheet/TimesheetUserTasksAdmin.php?action=list&sortfield=t.date_start&sortorder=desc&idmenu=168&mainmenu=timesheet&leftmenu=

Then I select and filter one employee, here the URL where I see the CSRF error :
https://dolibarr.mydomain.fr/custom/timesheet/TimesheetUserTasksAdmin.php

I don't see another URL in the browser than TimesheetUserTasksAdmin.php

[delcroip]

please recheck with 4.6.3,

[vidlb]

Hi, the error is still the same.
With MAIN_SECURITY_CSRF_WITH_TOKEN=0 ; here is the new log messages :

2023-03-23 08:53:45 NOTICE  193.251.52.139  --- Access to GET /custom/timesheet/core/js/jsparameters.php - action=, massaction=
2023-03-23 08:53:54 NOTICE  193.251.52.139  --- Access to POST /custom/timesheet/TimesheetUserTasksAdmin.php - action=, massaction=
2023-03-23 08:53:54 ERR     193.251.52.139  DoliDBPgsql::query SQL Error query: SELECT t.rowid,  t.fk_userid,  t.date_start,  t.date_end,  t.status FROM llx_project_task_timesheet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%2%') LIMIT 26
2023-03-23 08:53:54 ERR     193.251.52.139  DoliDBPgsql::query SQL Error message: ERROR:  42883: operator does not exist: integer ~~* unknown
LINE 1: ...eet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%2%...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
LOCATION:  op_error, parse_oper.c:722 (DB_ERROR_42883)
2023-03-23 08:53:54 ERR     193.251.52.139  DoliDBPgsql::query SQL Error usesavepoint = 0
2023-03-23 08:53:54 ERR     193.251.52.139  Error url=/custom/timesheet/TimesheetUserTasksAdmin.php, query_string=, sql=SELECT t.rowid,  t.fk_userid,  t.date_start,  t.date_end,  t.status FROM llx_project_task_timesheet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%2%') LIMIT 26, db_error=ERROR:  42883: operator does not exist: integer ~~* unknown
LINE 1: ...eet as t WHERE (t.fk_userid IN (1)) AND (t.status ILIKE '%2%...
                                                             ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
LOCATION:  op_error, parse_oper.c:722

[delcroip]

I found the CSRF issue thanks, the SQL is from the core I cannot do much

[vidlb]

All right, thanks @delcroip for looking into this. If the problem comes from dolibarr core, but it occurs with your module, what can I do ?
Looking at the error, it seems that this t.status column should be string, but is an integer.
Or is it a Postgres specific problem that the ILIKE operator does not work in that case ?

Which one could be fixed, this specific query with a type cast, or the column type in the table definition ?
In any case, I can't find it looking at the source code, I guess the query is dynamically built by a JS function or something like that...

[delcroip]

I will check if i can hint that it is a int