Bug #79175: AjaxWidgetContextHolder pollutes session data - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #79175

closed

AjaxWidgetContextHolder pollutes session data

Added by Dirk Wenzel over 7 years ago. Updated over 2 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Category:

Fluid

Target version:

Start date:

2017-01-05

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

7.0

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Summary
Ajax widgets do pollute the session data by storing their configuration on each page reload under a new identifier. Finally the session data grows too big to get loaded from the database.

Steps to reproduce

insert any Ajax widget into a page (e.g. f:widget.autocomplete)
reload the page a few times

watch the session data entry of the current user grow

SELECT hash, tstamp, LENGTH(content) FROM fe_session_data;

(tested under current versions of 6.2 and 7.6)

Findings
Any Ajax enabled widget instance restores its widgets context via an instance of AjaxWidgetContextHolder.
This class stores the content of its $widgetContext property to either the FE or BE user session under the key TYPO3\\CMS\\Fluid\\Core\\Widget\\AjaxWidgetContextHolder_widgetContexts (see method storeWidgetContexts()).
In the constructor the content of this key is restored into the property $widgetContext.

On each call of the method store() a new unique ajaxWidgetId is generated and the configuration of the widget is added to the $widgetContext array.
This behaviour leads to a constantly growing size of the session data. It is only interrupted if the user session invalidates (by expiration or deleting the fe_user_session cookie).

Conclusion
I'm not sure about the expected behaviour.
There seems to be a conceptual fault though: Since the page content with the widget will most probably be cached, only the first entry of the $widgetContext array will be used as argument fluid-widget-id for the widget action link.

Any suggestions are welcome.

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Bernhard Bücherl about 6 years ago

We ran into this issue today and solved it by patching sysext/fluid/Classes/Core/Widget/AjaxWidgetContextHolder.php with:

--- AjaxWidgetContextHolder.php    2018-03-08 15:11:32.525341048 +0100
+++ AjaxWidgetContextHolder.php    2018-03-08 15:11:46.818352835 +0100
@@ -88,7 +88,7 @@
      */
     public function store(\TYPO3\CMS\Fluid\Core\Widget\WidgetContext $widgetContext)
     {
-        $ajaxWidgetId = md5(uniqid(mt_rand(), true));
+        $ajaxWidgetId = md5(serialize($widgetContext));
         $widgetContext->setAjaxWidgetIdentifier($ajaxWidgetId);
         $this->widgetContexts[$ajaxWidgetId] = $widgetContext;
         $this->storeWidgetContexts();

I'm not sure if this is an appropriate fix for all use-cases but it does work for us

Actions

Copy link

Updated by Dirk Wenzel about 6 years ago

Bernhard Bücherl wrote:

I'm not sure if this is an appropriate fix for all use-cases but it does work for us

Hi Bernhard, thank you for your proposal.
It seems a bit strange: you serialize an instance of WidgetContext in order to generate an ID which is than stored in a property of the same instance.
Storing the md5-hash will change the signature of this object though.

I fear this ticket will be ignored by the core team. It seems fluid issues don't have any priority - let alone widgets...

cheers
Dirk

Actions

Copy link

Updated by Bernhard Bücherl about 6 years ago

Hi Dirk,

Dirk Wenzel wrote:

It seems a bit strange: you serialize an instance of WidgetContext in order to generate an ID which is than stored in a property of the same instance.
Storing the md5-hash will change the signature of this object though.

You are right, it would break when store(...) is called multiple times, but I did not see that happening.
Of course it would be cleaner not to store the ajaxWidgetIdentifier in the WidgetContext but to calculate it only when needed (e.g. having an generateAjaxWidgetIdentifier in WidgetContext).

Dirk Wenzel wrote: