eZ Community » Forums » eZ Publish 5 Platform » Public API: Search Service bug while...

Public API: Search Service bug while POST?

Public API: Search Service bug while POST?

Friday 23 August 2013 12:32:46 pm - 4 replies

Hi community,

we encountered a problem when using the search service while POST request (eZ 5.1 EE).

Situation: We have a simple POST request generated manually, not by Symfony forms or the like. Within that request, a search (via $ezpublishApiRepository->getSearchService()->findContent($query)) is done.

The search API finds content as I have the searched content within $content in the for loop in vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Search/Handler.php line 110. When the content has "ezimage", the loading of that field throws an exception: "Missing form token from Request"

I think, this is a bug, because the search API should not have any contact with the environmental context, neither when its done via HTTP GET nor HTTP POST or as a command script.

To reproduce, you need searchable content with an ezimage field and a simple findContent() call to the search service. This search must be called via simple HTTP POST request (without generated CSRF token):

Do you have any idea, why the exception is thrown or if it is my fault?

 try {
    /** @var Repository $ezpublishApiRepository */
    $searchService = $ezpublishApiRepository->getSearchService();
    $subTreePath = '/1/2';
    $fullText = 'Test content containing image';
    $query = new \eZ\Publish\API\Repository\Values\Content\Query();
    $query->criterion = new Criterion\LogicalAnd(
            new Criterion\Subtree($subTreePath),
            new Criterion\Visibility(Criterion\Visibility::VISIBLE),
            new Criterion\FullText($fullText),
    /** @var \eZ\Publish\API\Repository\Values\Content\Search\SearchResult $searchResult */
    $searchResult = $searchService->findContent($query);
    if (!$searchResult->totalCount) {
        return null;
} catch (\Exception $e) {
    return null;

The complete exception, which is thrown:

 Exception: Missing form token from Request in /PATH/ezpublish_legacy/extension/ezformtoken/event/ezxformtoken.php on line 148

Call Stack:
    // 1. to 9. is ommitted to enhance readability
    2.8733   25655432  10. eZ\Publish\Core\SignalSlot\SearchService->findContent(???, ???, ???) /PATH/TO/BUNDLE/myFile.php:X
    2.8734   25655856  11. eZ\Publish\Core\Repository\SearchService->findContent(???, ???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/SignalSlot/SearchService.php:67
    2.8948   26172352  12. eZ\Publish\Core\Persistence\Cache\SearchHandler->findContent(???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/SearchService.php:92
    2.9942   29773256  13. eZ\Publish\Core\Persistence\Legacy\Content\Search\Handler->findContent(???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Cache/SearchHandler.php:28
    3.2708   32016048  14. eZ\Publish\Core\Persistence\Legacy\Content\FieldHandler->loadExternalFieldData(???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/Search/Handler.php:112
    3.2721   32039768  15. eZ\Publish\Core\Persistence\Legacy\Content\StorageHandler->getFieldData(???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/FieldHandler.php:378
    3.2787   32190848  16. eZ\Publish\Core\FieldType\Image\ImageStorage->getFieldData(???, ???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Persistence/Legacy/Content/StorageHandler.php:95
    3.2789   32191392  17. eZ\Publish\Core\IO\IOService->loadBinaryFile(???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/FieldType/Image/ImageStorage.php:203
    3.2790   32191760  18. eZ\Publish\Core\IO\Handler\Legacy->load(???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/IO/IOService.php:189
    5.0582   32203680  19. eZ\Publish\Core\IO\Handler\Legacy->exists(???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/IO/Handler/Legacy.php:313
   10.1166   32214016  20. eZ\Publish\Core\IO\Handler\Legacy->getClusterHandler(???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/IO/Handler/Legacy.php:292
   24.8146   36106856  21. eZ\Publish\Core\MVC\Legacy\Kernel->runCallback(???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/IO/Handler/Legacy.php:471
   24.8146   36106904  22. ezpKernel->runCallback(???, ???) /srv/http/ez51/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/MVC/Legacy/Kernel.php:93
   24.8146   36106952  23. ezpKernelWeb->runCallback(???, ???) /srv/http/ez51/ezpublish_legacy/kernel/private/classes/ezpkernel.php:68
   24.8146   36108128  24. ezpKernelWeb->requestInit() /srv/http/ez51/ezpublish_legacy/kernel/private/classes/ezpkernelweb.php:1190
   24.8250   36383984  25. ezpEvent->notify(???, ???) /srv/http/ez51/ezpublish_legacy/kernel/private/classes/ezpkernelweb.php:1153
   24.8250   36384032  26. call_user_func_array(???, ???) /srv/http/ez51/ezpublish_legacy/kernel/private/classes/ezpevent.php:138
   24.8250   36384512  27. ezxFormToken::input(???) /srv/http/ez51/ezpublish_legacy/kernel/private/classes/ezpevent.php:138

Best regards,

Modified on Friday 23 August 2013 12:35:04 pm by Ryad-Marcel El-Dajani

Thursday 05 September 2013 7:50:19 pm



this is a bug, basically the event that ezformtoken listens to should not run on legacy runCallback().
Specifically ezpKernelWeb->runCallback() should be refactored to not run requestInit(), but this implies that requestInit() also needs to be refactored to move some of the logic to constructor.

I'm unsure how easily this can be done w/o causing any side effects.

Friday 06 September 2013 9:16:50 am

I'm all for that refactoring. Currently eZ runs way too much stuff when executing legacy-context code - and in real-world scenarios runCallback() might be called a dozen times in a page...

Friday 06 September 2013 9:46:04 am

Quote from Gaetano Giunta :

I'm all for that refactoring. Currently eZ runs way too much stuff when executing legacy-context code - and in real-world scenarios runCallback() might be called a dozen times in a page...

That's true. I'm not aware of the current community editions, but as far, as I know, a lot of missing data types (images, matrix, object relations) will be implemented as native field types in the next releases. Therefore the legacy calls will hopefully be decreased.

Furthermore we found out, that my mentioned bug is triggered when using eZ repository API with a logged in user, fetching an object containing a ezimage field.

Thanks for your help right now happy.gif Emoticon

Modified on Friday 06 September 2013 9:46:42 am by Ryad-Marcel El-Dajani

Tuesday 10 September 2013 12:11:15 pm

Hi community!

We posted this issue via enterprise bug tracker and Filipe Dobreira gave us a kind response to this issue.

While the appearance of that error message when bypassing symfony's form toolset seems odd, it can be explained by the way in which Form Token integration is implemented in eZ Publish - it is introduced as an event listener that captures all (or a large number of) non-idempotent requests, and enforces the presence of a form token as part of the request payload.
There are two ways to suppress this error:
- If you are not using eZFormToken's functionality, you may disable it for the affected siteaccess(es)
- If you want to manually create a form, you may 'manually' introduce the token as a hidden field in your form using the csrf_form twig helper:
<input type="hidden" name="ezxform_token" value="{{ csrf_token('legacy') }}">
The "legacy" parameter is the value for the intention argument - you may find additional information on this argument and CSRF protection in general in the following documentation page:

We already tried to disable CSRF functionality, but it did not work out. Also using the csrf_token Twig function did not work at first time. But with the "legacy" parameter, it works!

So for now, we use this csfr_token('legacy') Twig function each form. But of course, this is only a workaround and not a real solution.


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from