TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-02-01T12:11:22ZTYPO3 Forge
Redmine TYPO3 Core - Bug #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</p> TYPO3 Core - Bug #24784 (Closed): Workspaces module get place on "top" of all moduleshttp://forge.typo3.org/issues/247842011-01-25T01:12:26ZErnesto Baschnyeb@cron.eu
<p>After uninstalling the new sysext "info", the Workspaces module is on the first position of the modules menu (even before "Web>Page").</p>
<p>Since we moved several old hardcoded modules to sysext, they can also be uninstalled. Some extensions place their backend modules using the t3lib_extMgm::addModule() call and setting the $position parameter to one of these old hardcoded extensions.</p>
<p>E.g. the workspaces module registers himself for "before:info". So if "info" is not installed, the default would be to be placed "at the end". This is even documented in the method addModule(), but it doesn't work.</p>
<p>This is related to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a> and a follow-up after this fix was applied: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: New sysext modules are placed incorrectly in the Web> module menu (Closed)" href="http://forge.typo3.org/issues/24271">#24271</a><br />(issue imported from #M17282)</p> TYPO3 Core - Bug #24038 (Closed): SVG TypoScript object unuseable after tslib_content splituphttp://forge.typo3.org/issues/240382010-11-12T21:23:17ZErnesto Baschnyeb@cron.eu
<p>A minor typo in the ext_autoload makes the SVG not work anymore, because the class is not loaded.</p>
<p>(issue imported from #M16370)</p> TYPO3 Core - Bug #23499 (Closed): XHTML validity of backend when sys_action is loadedhttp://forge.typo3.org/issues/234992010-09-03T19:51:05ZErnesto Baschnyeb@cron.eu
<p>sys_action is able to generate links for the backend.php toolbar. The links with a href and "&" parameters, but this is not properly escaped (htmlspecialchars missing).</p>
<p>Solution is to escape the links, so that that part gets XHTML valid.</p>
<p>Problem is there since 4.3 where the toolbar was added.<br />(issue imported from #M15635)</p> TYPO3 Core - Bug #22780 (Closed): Web>List: Turning "Extended view" on makes rows growhttp://forge.typo3.org/issues/227802010-05-31T18:43:29ZErnesto Baschnyeb@cron.eu
<p>When turning "Extended view" on in list view will change the height of the individual data rows. Thus the icon that you just clicked to turn Extended view on is shifted downwards and more space is consumed on the screen.</p>
<p>My idea would be to leave the row height as it was before. An padding:2px around the div.typo3-DBctrl caused the grown.</p>
<p>Solution is to remove this padding. :)</p>
<p>See attached screenshots before and after the patch<br />(issue imported from #M14559)</p> TYPO3 Core - Bug #21333 (Closed): Sysext:lowlevel (function "DB>Full search") susceptible to XSShttp://forge.typo3.org/issues/213332009-10-22T10:34:54ZErnesto Baschnyeb@cron.eu
<p>Sysext:lowlevel provides, amongst others, a function called "Full Search" that allows to query the database directly. Both sub-functions "raw search in all fields" and "advanced query" are susceptible to XSS as both modules fail to sanitize results.</p>
<p>Reported by Markus Krause</p>
<p>Security Team OTRS reference: 2009091210000033 <br />(issue imported from #M12308)</p> TYPO3 Core - Bug #21332 (Closed): XSS in alt_palettehttp://forge.typo3.org/issues/213322009-10-22T10:28:47ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068<br />(issue imported from #M12307)</p> TYPO3 Core - Bug #21331 (Closed): XSS in module dispatcherhttp://forge.typo3.org/issues/213312009-10-22T10:21:39ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068<br />(issue imported from #M12306)</p> TYPO3 Core - Bug #21330 (Closed): tfID GET variable used in view_help.php is not sanitized and th...http://forge.typo3.org/issues/213302009-10-22T10:15:54ZErnesto Baschnyeb@cron.eu
<p>Sanitize tfID before using it.</p>
<p>Reporter: Jelmer de Hen</p>
<p>Security Team OTRS reference: 2009060310000056<br />(issue imported from #M12305)</p> TYPO3 Core - Bug #21329 (Closed): XSS in alt_mod_framesethttp://forge.typo3.org/issues/213292009-10-22T10:08:40ZErnesto Baschnyeb@cron.eu
<p>BE authentication required to exploit the vulnerability</p>
<p>TYPO3 Security Team OTRS reference: #2009061610000068 <br />(issue imported from #M12304)</p> TYPO3 Core - Bug #21328 (Closed): XSS vulnerability due to not proper sanitizing in function t3li...http://forge.typo3.org/issues/213282009-10-22T09:56:11ZErnesto Baschnyeb@cron.eu
<p>Reported by Andreas Schnapp.</p>
<p>Added missing escaping of the first parameter. Better description (and name) of the usage of parameter #2.</p>
<p>Reported by Andreas Schnapp</p>
<p>Security Team OTRS reference: 2009060910000027 <br />(issue imported from #M12303)</p> TYPO3 Core - Bug #20995 (Closed): stripSlashesOnArray creates references where you want copieshttp://forge.typo3.org/issues/209952009-09-04T15:08:36ZErnesto Baschnyeb@cron.eu
<p>In newer TYPO3 versions the class t3lib_div::stripSlashesOnArray has been optimized for performance, using a foreach loop where it used to be a while loop. The new version works on references instead of copying the array.</p>
<p>Problem:<br />After calling this function on a normal array, the array itself contains only references to the values it contained before. This ist quite ugly, cause you can't work on a copy without changing the original data any more.</p>
<p>Proposed Solution:<br />If you unset the reference at the end of foreach, you can go on using the array as before. This is recommended to do by the php.net documentation (in a big red "Warning" box) when using references in a "foreach" loop.</p>
<p>Issue might arise on any extension that makes use of t3lib_div::_GP. Bug was first noticed when trying to save mm-table-relations using sr_feuser_register:</p>
<p>here:<br /> function parseOutgoingData($origArr = array()) {<br /> (...)<br /> $parsedArr = $origArr;</p>
<p>$parsedArr is a COPY of our $this->dataArr, but it will modify the values from the original dataArr.</p>
<p>Since this is pretty difficult to test, attached is a very simple plugin which can be added to a page and it will explain and demonstrate the bug in "action".</p>
<p>Trouble was introduced in rev.3216 (feature <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Performance tunning : avoid low php-functions (Closed)" href="http://forge.typo3.org/issues/16375">#16375</a>):<br /><a class="external" href="http://forge.typo3.org/repositories/revision/typo3v4-core/3216">http://forge.typo3.org/repositories/revision/typo3v4-core/3216</a></p>
<p>So it was first included in 4.2.0beta2.<br />(issue imported from #M11876)</p> TYPO3 Core - Feature #19446 (Closed): substituteMarkerArrayCached is too strict for older extensionshttp://forge.typo3.org/issues/194462008-10-10T14:45:52ZErnesto Baschnyeb@cron.eu
<p>Many extensions using substituteMarkerArrayCached will fail in 4.3 as the function changed. All arguments has to be an array, otherwise you get following error:</p>
<p>Catchable fatal error: Argument [2,3,4] passed to tslib_cObj::substituteMarkerArrayCached() must be an array, null given</p>
<p>Thanks for Steffen Kamper for reporting. After some discussion in the -dev list, the idea came up to keep the type hinting but to allow the special case "null" (also uninitialized variable) to keep older extensions happy.</p>
<p>(issue imported from #M9533)</p> TYPO3 Core - Bug #18721 (Closed): Sorting in fields of type "group", "MM=1" and "multiple=1" is n...http://forge.typo3.org/issues/187212008-04-28T12:47:15ZErnesto Baschnyeb@cron.eu
<p>If I have a field defined like:</p>
<pre><code>'mitglieder_ag' => array(<br /> 'exclude' => 1,<br /> 'label' => 'LLL:EXT:cronmm_ratsinfo/locallang_db.xml:tx_cronmmratsinfo_gremium.mitglieder_ag',<br /> 'config' => array(<br /> 'type' => 'group',<br /> 'internal_type' => 'db',<br /> 'allowed' => 'tx_cronmmratsinfo_ausschussgemeinschaft',<br /> 'size' => 20,<br /> 'minitems' => 0,<br /> 'maxitems' => 100,<br /> 'multiple' => 1,<br /> 'selectedListStyle' => 'width:100px',<br /> 'MM' => 'tx_cronmmratsinfo_gremium_mitglieder_ag_mm',<br /> )<br /> ),</code></pre>
<p>that is with "MM=1" and "multiple=1", I am able to have a list where the same record occurs multiple times, e.g:</p>
<p>uid_foreign=45, sorting=1<br />uid_foreign=44, sorting=2<br />uid_foreign=44, sorting=3</p>
<p>After moving the entry 45 down one item (to get the list "44, 45, 44"), and I save the record, I end up with the following list:</p>
<p>45, sorting = 1<br />44, sorting = 3<br />44, sorting = 3</p>
<p>So not the desired sorting. I cannot separate the same uids: they will end up always being sorted in a "block".</p>
<p>The problem comes from t3lib_loaddbgroup::writeMM(), which cannot handle "multiple=1".</p>
<p>oldMMs:<br />45, 44, 44</p>
<p>the new itemArray in t3lib_loaddbgroup::writeMM():<br />44, 45, 44</p>
<p>In t3lib_loaddbgroup::writeMM() TYPO3 will execute the following UPDATEs:</p>
<p>UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 1 WHERE uid_local=1026 AND uid_foreign=44<br />UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 2 WHERE uid_local=1026 AND uid_foreign=45<br />UPDATE tx_cronmmratsinfo_gremium_mitglieder_ag_mm SET sorting = 3 WHERE uid_local=1026 AND uid_foreign=44</p>
<p>Notice that the last UPDATE will override what the first one did, so that we end up with the MM-table containing:</p>
<p>45, sorting = 2<br />44, sorting = 3<br />44, sorting = 3</p>
<p>and we would expect:</p>
<p>44, sorting = 1<br />45, sorting = 2<br />44, sorting = 3</p>
<p>Solution for "multiple=1" is to delete all records before we start and just write the new ones in the order they come in (with INSERT).<br />(issue imported from #M8279)</p> TYPO3 Core - Bug #15510 (Closed): UTF-8 sites display garbled chars in select-fields (in BE)http://forge.typo3.org/issues/155102006-01-26T16:50:33ZErnesto Baschnyeb@cron.eu
<p>Steps to reproduce (TCEforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)<br />3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.<br />4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string</p>
<p>Other place where it occurs (flexforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Add tt_news extension<br />3) Create a News Category called "ÖÖÖ" <br />4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".<br />5) Save and look at the displayed value in the left category box, its garbled again.</p>
<p>The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.</p>
<p>The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.</p>
<p>There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.</p>
<p>Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.</p>
<p>Initially reported for TYPO3 4.0<br />(issue imported from #M2396)</p>