When trying to access the default endpoint /rest/ there is this error:
{"success":false,"message":"An exception occurred: PHP Warning: Undefined array key 0 in /www/htdocs/w01ade75/dsw.wmk-dev.de/public/typo3conf/ext/interest/Classes/Router/HttpRequestRouter.php line 63","trace":[]}

Plugin-Version: 1.0.0-beta-7
Typo3-Version: 11.5.12

Steps to reproduce:

• Composer install interest without any modifications on the extension settings.
• Access default endpoint in frontend.

Describe the bug
With the TYPO3 update https://get.typo3.org/release-notes/12.4.10 on a PHP 8.2 setup the Symfony Console switched from 6.4 to 7.0
TYPO3/typo3@b03970d94d

The method signatures of some of the methods changed.
This leads to the following error message in all requests (frontend and backend)

To Reproduce
Steps to reproduce the behavior:

1. Update TYPO3 from 12.4.9 to 12.4.10
2. Open any page
3. See error

Fatal error: Declaration of Pixelant\Interest\Command\UpdateCommandController::execute(Symfony\Component\Console\Input\InputInterface $input, Symfony\Component\Console\Output\OutputInterface $output) must be compatible with Symfony\Component\Console\Command\Command::execute(Symfony\Component\Console\Input\InputInterface $input, Symfony\Component\Console\Output\OutputInterface $output): int in /var/www/html/.build/vendor/pixelant/interest/Classes/Command/UpdateCommandController.php on line 47

Expected behavior
All requests should work without errors.

Desktop (please complete the following information):

• OS: macOS, ddev
• Browser: all
• Version: all

Describe the bug
As the attributes of the operation objects change during the object's lifetime, the getHash() method is returning different hashes as different time. As a result the hash stored in the tx_interest_remote_id_mapping table's record_hash field is never the same as the one generated by the operation object in StopIfRepeatingPreviousRecordOperation and the StopRecordOperationException is never thrown.

To Reproduce
Re-run an operation twice and compare the record's tstamp field.

Expected behavior

The hash returned by the operation object should always be the same for the same operation, at any time during the operation's lifetime.

They should be lowercase.

Extension key: interest

Composer.json name: pixelant/interest

Configurable with extension configuration and environment variable (APP_INTEREST_LOG ). Possible values:

0 Disabled
1 Log in headers X-TYPO3-INTEREST-*
2 Log in database table
3 Both 1 and 2 (binary AND)

Value is minimum request execution time (milliseconds) for the request to be logged (APP_INTEREST_LOG_MS).

It is not possible to authenticate me.
$this->request->getHeader('authorization') is always empty because the 'authorization: basic... is not in the request variable.

TYPO3 11
interest 1.2.0

If i try to delete f.e. a page, i get a success message in response but nothing happened.
When i look at the log table, i see, that the request_body is empty.
POST and PUT are working. But no DELETE.

Thats the command: curl -XDELETE -H 'Authorization: bearer sdfadsgdfgdfgdfgdfg' 'https://www.domain.de/rest/pages/remoteID-page-1'

Response is: {"success":true,"message":"1 operation completed successfully."}

Log table says empty request_body.
And i can put as remoteID what i want. Always success and empty request_body.

What could be the issue?

TYPO3 11
interest 1.2.2

Describe the bug

With PR #85, introduced in version 1.1.4 of the extension, moves command definitions from Configuration/Commands.php and into Configuration/Services.yaml. This means it fixes commands for TYPO3 v11, but the command definitions won't be read in TYPO3 v9.

To Reproduce

Install the extension in TYPO3 v9 and try to run any CLI command. You will get the error: "There are no commands defined in the "interest" namespace."

Expected behavior

Commands should run in TYPO3 v9 as well as v10 and v11.

Suggested solution

Add a condition to the beginning of Configuration/Commands.php so the command configuration is only returned for TYPO3 versions below 10:

<?php

if (\Pixelant\Interest\Utility\CompatibilityUtility::typo3VersionIsGreaterThanOrEqualTo('10')) {
    return [];
}

return [
    'interest:create' => [

(I have tested this in TYPO3 v9 and v11, but not v10.)

Request:

curl -H "Authorization: 96d9cf18079e86359644" -XPUT \
https://main.ddev.site/rest/tx_pxaproductmanager_domain_model_product \
-d '{"remoteId":"AB20601D","data":{"blahxxx":"xyz"}}'

Return:

{"status":"success"}

Expected return:

Error response.

Describe the bug

When calling interest:create --update on a remote ID that exists or interest:update --create on a remote ID that doesn't exist and a StopRecordOperationException is thrown (e.g. by StopIfRepeatingPreviousRecordOperation) the exception is not caught and the script fails.

To Reproduce
Run a repeated interest:create --update CLI call that will trigger StopRecordOperationException in StopIfRepeatingPreviousRecordOperation.

Expected behavior

StopRecordOperationException should always be caught.

Backend module.

Describe the bug

When trying to delete a record, but the operation is unsuccessful, e.g. due to a permissions issue or another DataHandler error, the remote ID will still be deleted.

To Reproduce

Manually create a remote ID for a page, then try to delete the page using the extension, but authenticating with a user that doesn't have privileges to delete the page. The page will not be deleted, but the remote ID record will be gone.

Expected behavior

The remote ID should only be deleted when the related record has also been deleted.

Is your feature request related to a problem? Please describe.
GET might be used for many reasons, but one might be to control any desired manipulation only. This is not possible and in my opinion a major flaw of this extension.

Describe the solution you'd like
Add the HTTP method GET.

Describe the bug
In some cases a database deadlock will occur when the DataHandler is clearing caches. This rarely happens when executing manual updates, but can happen from time to time when large amounts of data are updated, such as in this extension.

To Reproduce
Can't be reproduced in any other way than to update a lot of records that trigger cache flushes.

Expected behavior
The DeadlockException thrown by Doctrine should be caught and clearing cache reattempted.

https://github.com/pixelant/inteREST/blob/dev/Classes/Handler/CrudHandler.php#L183

Missing parameter for exception, $request variable undefined.

Introduce support for PHP 8.2 in CI tests and code.

Describe the bug

Pending relations allow empty remote IDs to be written to the tx_interest_pending_relations table.

Expected behavior

Empty remote IDs should be removed/ignored.

Describe the bug

The authentication is currently using the format Authorization: [hash], where hash can either be a username/password pair separated by colon or a token.

To Reproduce

n/a

Expected behavior

• Password-based authentication should use Authorization: Basic [hash].
• Token-based authentication should use Authorization: Bearer [hash]

Additional context

More information:

Basic: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

Bearer: https://swagger.io/docs/specification/authentication/bearer-authentication/

if (!$this->dataHandling($data)) { is not enough. Also need if (!empty($dataHandler->errorLog)) { to catch errors.

In some part of the code there's undefined variables:

https://github.com/pixelant/inteREST/blob/dev/Classes/Handler/CrudHandler.php#L183

Here $responseFactory undefined, we haven't Request object inside of this function so $request also undefined, as well as this function returns only int values and not ResponseInterface.

https://github.com/pixelant/inteREST/blob/dev/Classes/Handler/CrudHandler.php#L226

I'm pretty sure here must be $table instead of $tableName

https://github.com/pixelant/inteREST/blob/dev/Classes/Handler/CrudHandler.php#L241

$foreignTable is also undefined

Describe the bug

UpdateRecordOperationTest overwrites $imageUpdates in a foreach loop, leading to an incorrect test.

interest 1.2.0
TYPO3 10

In TYPO3 11 it works without errors.
In TYPO3 10 i get the following error in tokenrepository.php

{"success":false,"message":"An exception occurred: Query result was not an instance of Doctrine\DBAL\Driver\Result","trace":[]}

my post is:
curl -XPOST -H 'Authorization: bearer XXXXXXXXX' 'http://domain.de/rest/pages' -d '{"data":{"remoteID-page-1":{"title":"Neue Seite"}},"metaData":{"storagePid":"39"}}'

If i debug $result->fetchOne() i get the error: {"success":false,"message":"An exception occurred: Call to undefined method Doctrine\DBAL\Driver\Mysqli\MysqliStatement::fetchOne()","trace":[]}

There is something wrong with backward compatible?

Add missing tests for the CommandControllers so we can discover bugs and API changes more easily.

Product type MYTYPE with uid 13 is in database.

Request:

curl -v -H "Authorization: 96d9cf18079e86359644" -XPUT \
https://main.ddev.site/rest/tx_pxaproductmanager_domain_model_product \
-d '{"remoteId":"MBL4","data":{"name":"MBL4","type":"MYTYPE"}}'

Result:

type = 0

Expected result:

type = 13

Call to undefined method Pixelant\Interest\Handler\BatchHandler::checkIfRelationExists()

Describe the bug

When creating an authentication token, it will only be accepted if the expiry is zero.

To Reproduce

Generate a token according to the manual. Authenticating with this token will not work.

Set the token's expiry to zero in the database. Authentication will work.

Expected behavior

Authentication with the token should work also without setting expiry to zero.