TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-03-21T06:42:10ZTYPO3 Forge
Redmine TYPO3 Core - Bug #100234 (Rejected): Incorporate tests of enshrined/svg-sanitize:v0.16.0http://forge.typo3.org/issues/1002342023-03-21T06:42:10ZOliver Haderoliver.hader@typo3.org
<p>It looks like the security release enshrined/svg-sanitize:v0.16.0 did not fix a real vulnerability and was a false-positive:</p>
<ul>
<li><a class="external" href="https://github.com/darylldoyle/svg-sanitizer/security/advisories/GHSA-xrqq-wqh4-5hg2">https://github.com/darylldoyle/svg-sanitizer/security/advisories/GHSA-xrqq-wqh4-5hg2</a></li>
<li><a class="external" href="https://nvd.nist.gov/vuln/detail/CVE-2023-28426">https://nvd.nist.gov/vuln/detail/CVE-2023-28426</a></li>
<li><a class="external" href="https://github.com/darylldoyle/svg-sanitizer/commit/cce18bc237c05c6e093e9672db7926788da9b322">https://github.com/darylldoyle/svg-sanitizer/commit/cce18bc237c05c6e093e9672db7926788da9b322</a></li>
</ul>
<p>Passing the two new added test files with the previous version v0.15.4 of that package did not reveal any valid attack vector - all entities are correctly encoded and would not have lead to an exploit in a browser context. This change in the TYPO3 context aims to demonstrate that there is no vulnerability.</p>
<ul>
<li><a class="external" href="https://github.com/darylldoyle/svg-sanitizer/blob/cce18bc237c05c6e093e9672db7926788da9b322/tests/data/cdataTwoTest.svg?short_path=025a153">https://github.com/darylldoyle/svg-sanitizer/blob/cce18bc237c05c6e093e9672db7926788da9b322/tests/data/cdataTwoTest.svg?short_path=025a153</a></li>
<li><a class="external" href="https://github.com/darylldoyle/svg-sanitizer/blob/cce18bc237c05c6e093e9672db7926788da9b322/tests/data/formDataTest.svg?short_path=b4118f0">https://github.com/darylldoyle/svg-sanitizer/blob/cce18bc237c05c6e093e9672db7926788da9b322/tests/data/formDataTest.svg?short_path=b4118f0</a></li>
</ul> TYPO3 Core - Bug #97669 (Rejected): Handle COA_INT in config.pageTitle TypoScript assignmenthttp://forge.typo3.org/issues/976692022-05-21T16:27:41ZOliver Haderoliver.hader@typo3.org
<p>Using deferred content rendering for the page title does not work, since <code>@ will be HTML-encoded in @PageRenderer</code> and corresponding post-processors in <code>TypoScriptFrontendController</code> are not considering <code>&lt--INT_SCRIPT.12345 --&gt</code>.</p>
<pre>
config {
noPageTitle = 1
pageTitle.cObject = COA_INT
pageTitle.cObject {
10 = TEXT
10.value = Page Title created during content rendering
}
}
</pre> TYPO3 Core - Bug #96179 (Rejected): Ensure URIs are parsed using plain POSIX/C localehttp://forge.typo3.org/issues/961792021-12-01T14:19:49ZOliver Haderoliver.hader@typo3.org
<p>Using <code>parse_url</code> on unicode characters and not using a plain POSIX/C locale might lead to negative side-effects, destroying the unicode sequence of those special characters.</p>
<p>See attached <code>locale.php</code> to local locale testing.</p>
<a name="References"></a>
<h3 >References<a href="#References" class="wiki-anchor">¶</a></h3>
<ul>
<li><a class="external" href="https://bugs.php.net/bug.php?id=52923">https://bugs.php.net/bug.php?id=52923</a></li>
<li><a class="external" href="https://github.com/TYPO3/testing-framework/pull/313">https://github.com/TYPO3/testing-framework/pull/313</a></li>
</ul> TYPO3 Core - Bug #92985 (Rejected): Cannot show record history of pages anymore in TYPO3 v10.4.10http://forge.typo3.org/issues/929852020-12-04T08:59:10ZOliver Haderoliver.hader@typo3.org
<blockquote>
<p>(1/3) Doctrine\DBAL\Exception\InvalidFieldNameException<br />An exception occurred while executing 'SELECT `uid` FROM `tx_impexp_presets` WHERE `pid` = ?' with params > [81]: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'pid' in 'where clause'</p>
<p>...</p>
<p>at TYPO3\CMS\Core\Database\Query\QueryBuilder->execute()<br />typo3/sysext/backend/Classes/History/RecordHistory.php line 328</p>
</blockquote>
<p>How to reproduce:</p>
<ul>
<li>(update TYPO3 v10.4.9 to v10.4.10)</li>
<li>(impexp system extension must be enabled)</li>
<li>use context menu in page-tree to show record history</li>
</ul>
<p>Reasons:</p>
<ul>
<li>looks like <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/66582">https://review.typo3.org/c/Packages/TYPO3.CMS/+/66582</a> changes database definition and introduces new TCA table</li>
<li>records history iterates over all TCA tables - applying <code>pid</code> constraint for <code>pages</code></li>
<li><code>pid</code> column does not exist unless database migration in Install Tool was executed (which should not be required for patch level releases)</li>
<li>affects TYPO3 v10 only</li>
</ul> TYPO3 Core - Bug #91432 (Rejected): PageRepository PageRepository_hidDelWhere cache should consid...http://forge.typo3.org/issues/914322020-05-18T21:58:18ZOliver Haderoliver.hader@typo3.org
<p>Looking into <code>PageRepository::enableFields</code> reveals that the cache-identifier probably should have more information, e.g. some "state-hash" of the currently applied Context.</p>
<a name="Currently-considered"></a>
<h3 >Currently considered<a href="#Currently-considered" class="wiki-anchor">¶</a></h3>
<ul>
<li>show-hidden - context:visibility/includeHiddenPages</li>
<li>workspace ID - context.workspace.id</li>
</ul>
<a name="Probably-not-considered"></a>
<h3 >Probably not considered<a href="#Probably-not-considered" class="wiki-anchor">¶</a></h3>
<ul>
<li>starttime/endtime - context:date/accessTime</li>
<li><del>fe_group - context:frontend.user/groupIds (has it's own cache - but does not modify <code>PageRepository_hidDelWhere</code> cache identifier)</del>
<ul>
<li>not affected, since excluded with <code>$ignore_array</code> in <code>init</code> method</li>
</ul></li>
</ul>
<a name="Expected-impact"></a>
<h3 >Expected impact<a href="#Expected-impact" class="wiki-anchor">¶</a></h3>
<p>Using <code>PageRepository</code> without taking these two additional aspects into account, it might happen that invoking <code>PageRepository</code> multiple times with different contexts (having different aspects for date and frontend.user) leads to unexpected results - basically, the first <code>PageRepository</code> invocation defined the where clause.</p> TYPO3 Core - Bug #89311 (Rejected): Flaws in site configuration when creating new page on root-levelhttp://forge.typo3.org/issues/893112019-09-30T12:07:51ZOliver Haderoliver.hader@typo3.org
<p>Scenario: Create a new site on root-level, which leads to auto-generation of site configurationin typo3conf/sites/ (or config/sites/ in composer mode)</p>
<ul>
<li>site configuration is not created for (nested) page having <code>is_siteroot</code> enabled (compare with SlugHelper)</li>
<li>creating a sys folder on root-level (pid: 0) and changing page type to standard later does not create site configuration</li>
</ul> TYPO3 Core - Bug #87303 (Rejected): Disable autocomplete for login formshttp://forge.typo3.org/issues/873032018-12-27T14:12:09ZOliver Haderoliver.hader@typo3.org
<p>In order to apply strong security defaults it is suggested to disable autocomplete of login forms.</p>
References:
<ul>
<li><a class="external" href="https://portswigger.net/kb/issues/00500800_password-field-with-autocomplete-enabled">https://portswigger.net/kb/issues/00500800_password-field-with-autocomplete-enabled</a></li>
</ul> TYPO3 Core - Bug #85950 (Rejected): Preview URL in backend is invalidhttp://forge.typo3.org/issues/859502018-08-23T18:40:46ZOliver Haderoliver.hader@typo3.org
Scenario:
<ul>
<li>not having site configuration</li>
<li>not having pseudo-site (no sys_domain configuration)</li>
<li>generate preview URL using record's context menu "view"</li>
</ul>
Result:
<ul>
<li><code>http://http//ip9.local/index.php?id=205</code></li>
</ul>
Expectation:
<ul>
<li><code>http://ip9.local/index.php?id=205</code></li>
</ul> TYPO3 Core - Bug #85000 (Rejected): Cannot add image using element browserhttp://forge.typo3.org/issues/850002018-05-14T15:40:54ZOliver Haderoliver.hader@typo3.org
<a name="Steps"></a>
<h2 >Steps<a href="#Steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>backend, edit tt_content in FormEngine of type text/image</li>
<li>open add new image dialog</li>
<li>after selecting image (SVG in this case) console error is shown</li>
</ul>
<a name="Misbehavior"></a>
<h2 >Misbehavior<a href="#Misbehavior" class="wiki-anchor">¶</a></h2>
<p>Console error <code>Uncaught TypeError: Cannot read property 'data-52-tt_content-472-image-sys_file_reference' of undefined</code><br />Refers to <code>jsfunc.inline.js</code> in method <code>getContext: function(objectId)</code></p> TYPO3 Core - Bug #39968 (Rejected): Collections use t3lib_BEfunchttp://forge.typo3.org/issues/399682012-08-19T15:43:17ZOliver Haderoliver.hader@typo3.org
<p>t3lib_collections use e.g. t3lib_BEfunc calls that won't work in the frontend.</p> TYPO3 Core - Bug #39727 (Rejected): Calculating percentage of differences is slowhttp://forge.typo3.org/issues/397272012-08-12T15:32:20ZOliver Haderoliver.hader@typo3.org
<p>The workspace view in the backend has a feature to calculate the percentage of differences between live and workspace version.<br />This implementation iterates over each record and each field by using the PHP method similar_text().<br />The complexity of similar_text() is measured with O(n^3) which quickly can turn into a nice waiting period if string length is more than approx 4000 characters.</p>
Changes:
<ul>
<li>use a different approach if string length is more than 2048 or 4096 characters</li>
<li>remove MD5 sums on files which also can turn out in a nice waiting period</li>
<li>do not resolve fields that hold m:n relations to reduce tree complexity and database queries</li>
</ul>
<p>Maybe disable this feature in newer versions at all or us a simple MD5 based comparison of the field contents which reads then "n% of the all fields have been modified".</p> TYPO3 Core - Bug #38488 (Rejected): IRRE - Children cannot be expanded anymorehttp://forge.typo3.org/issues/384882012-06-29T17:00:50ZOliver Haderoliver.hader@typo3.org
<p>This is a follow-up to issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: IRRE hide/unhide broken in master (Closed)" href="http://forge.typo3.org/issues/34303">#34303</a></p>
<p>Child records that are collapsed cannot be expanded anymore by clicking the child records's title in TCEforms.</p>
<p>JavaScript error message:<br />document.getElementsByName(elName + "[hidden]")[0] is undefined</p> TYPO3 Core - Bug #31613 (Rejected): pi_list_browseresults misses SPAN_BEGIN substitutionhttp://forge.typo3.org/issues/316132011-11-06T13:11:53ZOliver Haderoliver.hader@typo3.org
<p>This issues happens in combination with tt_news which defines the label "pi_list_browseresults_displays" with a SPAN_BEGIN marker.<br />The replacement of this marker is already if the wrapper array does not define the "showResultsNumbersWrap" property, however it is missing if the property is defined.</p>
<p>The faulty result might look like this:<br /><pre>
<div class="showResultsWrap">News ###SPAN_BEGIN###%s bis %s von ###SPAN_BEGIN###%s</div>
</pre></p> TYPO3 Core - Bug #28955 (Rejected): Flushing database caches truncates table before dropping ithttp://forge.typo3.org/issues/289552011-08-12T21:38:37ZOliver Haderoliver.hader@typo3.org
<p>The database backend of the caching framework first truncates tables before dropping them.<br />This happens on calling the flush() method there and seems not to be required at all.</p> TYPO3 Core - Bug #23521 (Rejected): Flash Uploader does not work if cookieHttpOnly is enabledhttp://forge.typo3.org/issues/235212010-09-09T13:10:57ZOliver Haderoliver.hader@typo3.org
<p>The Flash Uploader does not work if the TYPO3_CONF_VARS setting "cookieHttpOnly" is enabled. After uploading a file, the uploader just shows a "303" error.</p>
<p>"303" is a HTTP status code and tells that there was a redirect since the backend user could not be authorized to have access to the TYPO3 backend.</p>
<p>(issue imported from #M15673)</p>