I've recently upgraded to version 7.3.4 and found the API search behaves differently to earlier versions.
I have a project and test session in that project. The test session is currently assigned to the user with id 3.
I have another user with id 4, who is also a resource on the project.
If I use this user to issue the request
/api/TestSession/search/idresource=4 then the test session is returned, even though the idresource field clearly has the value 3
I also get the same response if I use any value as the user id even ones where there is no user with the value passed in the request.
Earlier versions always returned an empty items array unless the request parameter matched the value in the record.
I've trapped some of the SQL generated and around line 193 in the api/index.php file, the program adds some clauses to the where clause generated from the request parameters. These appear to be a mixture of and and or terms, the end result seems to be that the answer is always true. Maybe mysql and pgsql interprets the priorities of and and or differently.
A possible solution (and I'm not sure it's the correct one) seems to be to wrap the results of the getAccessRestrictionClause function in parentheses, so line 193 becomes:
$where.=' and ( '.getAccessRestrictionsClause($class,null,true) .' ) ';
I guess the change in behaviour is a result of a change in the .getAccessRestrictionsClause function.
I have a project and test session in that project. The test session is currently assigned to the user with id 3.
I have another user with id 4, who is also a resource on the project.
If I use this user to issue the request
/api/TestSession/search/idresource=4 then the test session is returned, even though the idresource field clearly has the value 3
I also get the same response if I use any value as the user id even ones where there is no user with the value passed in the request.
Earlier versions always returned an empty items array unless the request parameter matched the value in the record.
I've trapped some of the SQL generated and around line 193 in the api/index.php file, the program adds some clauses to the where clause generated from the request parameters. These appear to be a mixture of and and or terms, the end result seems to be that the answer is always true. Maybe mysql and pgsql interprets the priorities of and and or differently.
A possible solution (and I'm not sure it's the correct one) seems to be to wrap the results of the getAccessRestrictionClause function in parentheses, so line 193 becomes:
$where.=' and ( '.getAccessRestrictionsClause($class,null,true) .' ) ';
I guess the change in behaviour is a result of a change in the .getAccessRestrictionsClause function.