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 #98642 (Rejected): Remove dependency injection from resource controllerhttp://forge.typo3.org/issues/986422022-10-17T21:51:58ZOliver Haderoliver.hader@typo3.orgTYPO3 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 #84503 (Rejected): Streamline RsaAuth login behaviorhttp://forge.typo3.org/issues/845032018-03-21T08:32:21ZOliver Haderoliver.hader@typo3.org
<a name="Short-summary"></a>
<h2 >Short summary<a href="#Short-summary" class="wiki-anchor">¶</a></h2>
<ul>
<li>regression in TYPO3 v7.6.25 and v8.7.11 when trying to log into the backend using a regular workflow (fill form, click login button)</li>
<li>basically affects Firefox (except macOS version) browsers - e.g. Chrom is not affected by this misbehavior</li>
</ul>
<a name="TYPO3-releases"></a>
<h2 >TYPO3 releases<a href="#TYPO3-releases" class="wiki-anchor">¶</a></h2>
<p>Updated TYPO3 versions 7.6.26 and 8.7.12 (to substitute 7.6.25 and 8.7.11) are planned to be released on Thursday, March 22nd, 2018.</p>
<a name="Side-note-on-RsaAuth"></a>
<h2 >Side note on RsaAuth<a href="#Side-note-on-RsaAuth" class="wiki-anchor">¶</a></h2>
<p>System extension "rsaauth" provides a public/private key encryption mechanism to for user credentials that are submitted using an insecure channel (e.g. plain HTTP on port 80). In case a web site is using secure channels (e.g. HTTPS on port 443) the system extension "rsaauth" can be disabled completely in combination with changing the <code>loginSecurityLevel</code> setting in the install tool for frontend and backend from <code>rsa</code> to <code>normal</code> - RsaAuth is superfluous in case the communication to the server is secured via TLS (HTTPS) already.</p>
<p>In general it's suggested to use HTTPS instead of RsaAuth!</p>
<a name="Explanation"></a>
<h2 >Explanation<a href="#Explanation" class="wiki-anchor">¶</a></h2>
<p>The fix for issue <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: rsaauth does not submit the name of the submit-button (Rejected)" href="http://forge.typo3.org/issues/76120">#76120</a> - which was targeted to work-around situations when a login form has two submit buttons with different meanings/actions - introduce a regression which lead to the situation that users could not login anymore into the TYPO3 backend.<br />The mentioned regression was handled in issue <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: BE Login with 8.7.11 and Firefox Quantum Browser Version 59.0 not possible anymore (Closed)" href="http://forge.typo3.org/issues/84253">#84253</a> which introduced a work-around for the TYPO3 backend part.</p>
A short summary what happened in the JavaScript part handling the login process:
<ul>
<li>extensions like sr_feuser_register combine different actions by using different name attributes on submit buttons in the same containing form element - in general using different endpoint actions would be suggested instead of combining the meaning in the same form</li>
<li>the mentioned first work-around change tries to preserve the name attribute of the clicked button to be send with the very same form - this was necessary since the button gets disabled once it was clicked (to prevent resubmission and clicking multiple times) - disabled form element are not delivered in the <code>application/x-www-form-urlencoded</code> part of the HTTP message to the server</li>
<li>the change that introduced the first regression was focusing on button that has been clicked by checking the <code>:focus</code> state of the button and tried to click that again - since the button already became disabled, it also cannot be clicked again and wont actually send the form contents to the server</li>
<li>the behavior basically affects FIrefox (excluding macOS versions, see below)
<ul>
<li>Firefox does not support <code>click</code> events on disabled form elements, see <a class="external" href="https://developer.mozilla.org/en-US/docs/Web/Events/click#Browser_compatibility">https://developer.mozilla.org/en-US/docs/Web/Events/click#Browser_compatibility</a> - this applies e.g. to Edge as well</li>
<li>several browsers set the <code>:focus</code> state when clicking an element, except Firefox and Safari on macOS</li>
<li>the combination of these criteria lead to the mentioned misbehavior and explain why e.g. Chrome is not affected, see <a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus</a></li>
</ul></li>
</ul>
To streamline the behavior the following has to be done:
<ul>
<li>revert both changes, the one that introduced the regression and the other that fixed the regression in the backend scope</li>
<li>(optionally) re-implement the initial bug fix for <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: rsaauth does not submit the name of the submit-button (Rejected)" href="http://forge.typo3.org/issues/76120">#76120</a> without touching the backend part and only focussing carefully on the frontend part</li>
</ul> TYPO3 Core - Bug #78743 (Rejected): Wrong translation behavior for pages/pages_language_overlayhttp://forge.typo3.org/issues/787432016-11-18T13:30:30ZOliver Haderoliver.hader@typo3.org
<ol>
<li>on localizing a page, references of <code>pages.media</code> are not copied to <code>pages_language_overlay.media</code> in DataHandler if <code>localizeChildrenAtParentLocalization</code> is defined in TCA</li>
<li>RootlineUtility is not capable of resolving overlays correctly, ignores <code>l10n_mode</code> and uses custom reference queries -> RelationHandler could be used here</li>
</ol> 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>