Closed vidlb closed 1 year ago
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.
@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 ?
It seems an ( is missing
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.
So you can confirm the CRSF token error may be due that SQL typo ? If so the error message is misleading.
should be fixed with 4.6.2, reopen issue if not
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
Can you paste the url on which you have the error message, i couldn't find it.
Br
It's /custom/timesheet/TimesheetUserTasksAdmin.php
I mean in the browser, I tried to update all actions but I must have missed one
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
please recheck with 4.6.3,
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
I found the CSRF issue thanks, the SQL is from the core I cannot do much
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...
I will check if i can hint that it is a int
Steps to reproduce :
When clicking on the filter button, a blank page appear with the following message :
I'm not behind a reverse proxy. Dolibarr version is latest 16.0 (updated via git pull), module is 4.6.0 Ubuntu 20.04 / PHP 7.4 + PostgreSQL 12
In the main log file :