Bug #21388
closedtypo3temp got filled with thousands of javascript_* files
Added by Mittwald CM about 15 years ago. Updated over 10 years ago.
0%
Description
If you use "GMENU_LAYERS / TMENU_LAYERS" without a specific "layer_menu_id" then your typo3temp will be filled continously with javascript_* files.
TSref:
layer_menu_id
string
If you want to specifically name a menu on a page. Probably you don't need that!
This is wrong, you SHOULD set it to avoid this bug if it's not fixed.
The unique filename is created with a string md5(microtime()).
(Actually it's intended to be unique.)
md5(microtime()) can create millions of different filenames causing typo3temp to be filled more and more.
Problems with temporary files with unique filenames are also mentioned in Bug #21387 (http://bugs.typo3.org/view.php?id=12375).
This bug can also show DoS-like behaviour.
The applied patch is a dirty bugfix. It replaces microtime() with a string built around env var TYPO3_HOST_ONLY.
A better fix should use a system wide (system=TYPO3) class-function especially written for purposes like this.
(issue imported from #M12376)
Files
typo3-4.2.9-no-typo3temp-fill-with-javascript.patch (1.97 KB) typo3-4.2.9-no-typo3temp-fill-with-javascript.patch | Administrator Admin, 2009-10-28 11:37 | ||
patch-12376.patch (1.76 KB) patch-12376.patch | Administrator Admin, 2009-10-29 12:53 | ||
typo3-4.3.2-no-typo3temp-fill-with-javascript.patch (1.92 KB) typo3-4.3.2-no-typo3temp-fill-with-javascript.patch | Administrator Admin, 2010-03-17 11:58 | ||
typo3-4.3.2-no-typo3temp-fill-with-javascript-2.patch (1.92 KB) typo3-4.3.2-no-typo3temp-fill-with-javascript-2.patch | Administrator Admin, 2010-03-17 12:15 | ||
typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch (1.51 KB) typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch | Administrator Admin, 2010-03-29 17:10 | ||
12376_v4.diff (1.62 KB) 12376_v4.diff | Administrator Admin, 2010-10-03 03:07 |
Updated by Georg Ringer about 15 years ago
Additional information - How to reproduce:
1.) Delete temp js files in typo3temp
2.) Create a Layer_menu with a code like this
page.20 = HMENU page.20 { 1 = TMENU_LAYERS 1 { wrap=<table border="0" cellspacing="0" cellpadding="0">|</table> layerStyle = position:absolute;VISIBILITY:hidden;border: 1px solid #CCCCCC; background: #ffffff; lockPosition = y hideMenuWhenNotOver = 1 hideMenuTimer=250 expAll=1 leftOffset = 0 topOffset =22 relativeToTriggerItem = 1 NO { allWrap=<td>|</td> ATagParams = class = "menue" } } 2 = TMENU 2.NO { ATagParams = class = "menue1" allWrap=|<br> } }
3.) click around and look at the typo3temp/ it will get larger with every click.
Updated by Jorgo S. almost 15 years ago
Hi Georg,
thanks for the patch! I tried the generic one on Typo3 4.3 and unfortunately, js and css files are still being generated. Anything I can do to help troubleshoot this?
Updated by Mittwald CM almost 15 years ago
Hi @all review,
@Georg: Your patch differs from my original patch. Did it happen accidentally or was it your intent?
Frank:
md5('gl' ...
md5('tl' ...
Georg:
md5('tl' ...
md5('tl' ...
@Jörg: The patch was created when doing some research for an article in german T3N magazine. Are you sure that the patch did succeed without any error? Is it possible that the class files are cached in any way and the cached files and not the patched files are used? Can you give me some examples of js filenames? There may be still another bug which affects also css files. Then there will be more research needed.
regards,
Frank
Updated by Jorgo S. almost 15 years ago
Hi Frank,
I think I had a caching problem after applying the patch before. Now, no more .js files are accumulated, thanks again!
Updated by Mittwald CM over 14 years ago
Hi @all review,
it looks like nobody cares about this bug. Maybe there should be more users with 2 million .js files in typo3temp like posted on twitter a few days before. ;-)
Hint: If your typo3temp is grown and you have to delete many thousands of files then the small linux-tools "direntries" (part of the sac-tools software suite) may be useful for you.
Example: direntries -D -e .js typo3temp
It will delete the .js files faster than any other tool on linux.
Updated by Mittwald CM over 14 years ago
A new patch is available.
As an additional string for creating the ID a serialized representation of the menu array variable menuArr is used.
Updated by Mittwald CM over 14 years ago
Updated by Vahan Amirbekyan over 14 years ago
the patch for 4.2.9 worked for me on 4.2.6
the patch for 4.3.2 did not work for me though on 4.3.2
Should anything else be applied together with this patch(s)?
Updated by Mittwald CM over 14 years ago
@Vahan:
Please try the simplified patch typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch.
Compare the patched files with their originals to see the small difference.
The patch should fit for all TYPO3 versions (with a little offset).
Updated by Jorgo S. over 14 years ago
I thought this was already fixed in Typo3 4.4(x). Now I just realized that after updating, I had another 4600 .js files in my temp folder...
Updated by Chris topher over 14 years ago
Hi guys,
please send a reminder to the thread in Core List, so that this problem gets a bit more attention.
Thank you!
Updated by Jorgo S. about 14 years ago
I've used typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch on Typo3 4.4.2 and it doesn't seem to have any effect. Anybody else?
Updated by Mittwald CM about 14 years ago
Hi Jorgo,
on 2009-12-14 you wrote that you already had a "caching problem" (solved).
Now we try it again. :-)
1) Did you verify that the files are actually patched?
2) Are you sure that there are no copies of these on other places installed and "activated"?
3) Did you check for Bug #22311?
4) Do you use GTMENU (http://wiki.typo3.org/wiki/GTMENU)?
If you can't solve it please post the last few lines of an example typo3temp/*.js file.
I've successfully patched hundreds of TYPO3 installations.
Frank
Updated by Lars Houmark about 14 years ago
I have just bumped the core list with a new CGL version of the patch after my testing of v3. Let's hope this one gets solved soon. It certainly have waited long enough. Will attach the patch here for reference.
Updated by Steffen Kamper about 14 years ago
committed to svn
4_2 rev 9035
4_3 rev 9036
4_4 rev 9037
trunk rev 9038
Updated by Jorgo S. over 13 years ago
As per various posts of mine in the newsgroups, I had advised that
In my typo3 4.4.4 there are 2 identical versions of the script. One
resides in
\typo3\sysext\cms\tslib\media\scripts\
and this is where the patch header points to.Another version resides in
\typo3\sysext\statictemplates\media\scripts\
and only after I had patched those files as well did the creation of
new .js files stop.
Also, in Typo3 4.5.3, different (older) versions of the files than in 4.5.2 seem to have been included.
Updated by Jorgo S. over 13 years ago
I've advised about this bug in the Bug Day Wiki http://wiki.typo3.org/BugDay/201105, in the newsgroups and here, yet nobody seems to want to fix it as 4.5.4 came out with it AGAIN.
Updated by Xavier Perseguers over 13 years ago
- Status changed from Resolved to Needs Feedback
- Assignee deleted (
Steffen Kamper) - Priority changed from Should have to Must have
- Target version deleted (
0)
Reopen the bug and waiting for further tests/feedback/...
Updated by Kay Strobach almost 13 years ago
why not using md5(json_encode($config_array)) as name for the js file?! this way you would only get a new file, if the config changes.
I have not spent time to digg into the issue's code, but i think this could be a solution
Regards
Kay
Updated by Steffen Gebert almost 13 years ago
To be honest, I don't exactly understand the problem (at least not under which circumstances it exists).
What's with the option layer_menu_id
? Does that help?
The patch mentioned here was obviously only applied to the file in cms/tslib/
, but not in statictemplates/
. But, if I don't get you wrong, this one doesn't work, too?
Updated by Steffen Gebert almost 13 years ago
Example code by Sergey Alexandrov:
page.includeLibs.tmenu_layers=media/scripts/tmenu_layers.php temp.topmenu=HMENU temp.topmenu { 1 = TMENU_LAYERS 1 { expAll=1 relativeToTriggerItem=1 relativeToTriggerItem.addHeight=1 displayActiveOnLoad=0 freezeMouseover=1 hideMenuWhenNotOver=1 topOffset=15 wrap = <tableborder="0"cellpadding="0"cellspacing="0"class="level1"align="center"><tr>|</tr></table> NO.allWrap = <tdclass="level1"align="left">|</td> } 2 = TMENU_LAYERS 2 { hideMenuWhenNotOver=1 wrap=<tableborder="0"cellpadding="0"cellspacing="0"class="level2">|</table> NO.allWrap=<tr><tdclass="level2">|</td></tr> } }
Updated by Steffen Gebert almost 13 years ago
I still cannot reproduce this. What's the difference between all these files' contents?
Updated by Christian Kuhn over 11 years ago
- Status changed from Needs Feedback to Rejected
With 6.1 issue #46358, the _layers menus where moved to statictemplates, and statictemplates was removed from core afterwards. This issue won't be solved in the core anymore.
Updated by Jorgo S. over 11 years ago
Wow... 2 years of nothing and then this is what the community gets? What about the 4.x versions???
Updated by Artur Cichosz over 10 years ago
Just for reference in case somebody still has this problem with TYPO3 4. The patches disscussed here did work in our case.
We actually did set the tmenu_layers and gmenu_layers script excplicitely, so there is no issue with different locations of that scripts among different TYPO3 versions.
page.includeLibs.tmenu_layers=...
This worked for almost a year but today for some reason we had double function definitions caused by the same identifier generated twice inside the DHTML menu JavaScript code.
Now the Menu didn't work as expected and some layers just didnt got hidden on mouse out.
To fix this again without too much digging I just changed the critcal line of code from this
$this->WMid = trim($this->mconf['layer_menu_id'])?trim($this->mconf['layer_menu_id']).'x':substr(md5('tl'.serialize($this->result)),0,6);
to this
$this->WMid = trim($this->mconf['layer_menu_id'])?trim($this->mconf['layer_menu_id']).'x':substr(md5('tl'.serialize($this->result).$this->id),0,6);
Now it works again.