TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-12-06T21:30:04ZTYPO3 Forge
Redmine TYPO3 Core - Task #102620 (Closed): Add strict parameter to base64url decodehttp://forge.typo3.org/issues/1026202023-12-06T21:30:04ZOliver Haderoliver.hader@typo3.org
<p>Taken from <a class="external" href="https://forge.typo3.org/issues/102438#note-11">https://forge.typo3.org/issues/102438#note-11</a></p>
<p>PHP's <code>base64_decode</code> has a strict parameter to only accept characters of the corresponding base64 alphabet, see <a class="external" href="https://www.php.net/manual/en/function.base64-decode.php">https://www.php.net/manual/en/function.base64-decode.php</a></p> TYPO3 Core - Task #102610 (Closed): Revert "[BUGFIX] Set HTTP timeout to 20 seconds"http://forge.typo3.org/issues/1026102023-12-06T10:10:08ZOliver Haderoliver.hader@typo3.org
<p>The change for issue <a class="issue tracker-1 status-8 priority-3 priority-lowest" title="Bug: Update Guzzle timeout to 20 seconds (Under Review)" href="http://forge.typo3.org/issues/102606">#102606</a> has the potential to do more harm than good.</p>
<p>The initial intention was to define a HTTP timeout to be lower than the PHP <code>max_execution_time</code>.<br />Defining general timeout of 20 seconds now also limits e.g. long running CLI processes (e.g. importing data).</p>
<p>→ corresponding discussion in Slack: <a class="external" href="https://typo3.slack.com/archives/C03AM9R17/p1701850585082239?thread_ts=1701810994.856119&cid=C03AM9R17">https://typo3.slack.com/archives/C03AM9R17/p1701850585082239?thread_ts=1701810994.856119&cid=C03AM9R17</a>)</p> TYPO3 Core - Bug #101460 (Resolved): Allow strict-dynamic only for applicable CSP directiveshttp://forge.typo3.org/issues/1014602023-07-27T10:56:06ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #100732 (Closed): Allow f:asset.css and f:asset.script to use CSP noncehttp://forge.typo3.org/issues/1007322023-04-24T15:03:29ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #99366 (Closed): Add backward compatibility handling for frontend loginhttp://forge.typo3.org/issues/993662022-12-14T11:10:51ZOliver Haderoliver.hader@typo3.org
<p>Security fix for TYPO3-CORE-SA-2022-013 in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/77084">https://review.typo3.org/c/Packages/TYPO3.CMS/+/77084</a> enforced the existence of an HMAC signed <code>pid</code> value. There have been reports in custom authentication services, where this might be problematic (albeit it could be solved). To provide better backward compatibility, a new feature flag is introduced.</p> TYPO3 Core - Feature #95054 (Under Review): Add possibility to add HTTP headers in frontendhttp://forge.typo3.org/issues/950542021-08-31T13:46:32ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #92509 (Closed): Add base64url encode/decode functionalityhttp://forge.typo3.org/issues/925092020-10-07T20:04:34ZOliver Haderoliver.hader@typo3.org
<p>Add static library functions that allow using base64url-compliant values (according to <a class="external" href="https://tools.ietf.org/html/rfc4648#section-5">https://tools.ietf.org/html/rfc4648#section-5</a>) - this also avoids duplications in user-land code.</p> TYPO3 Core - Task #91242 (Closed): ...http://forge.typo3.org/issues/912422020-04-30T13:01:32ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #87666 (Closed): Add language synchronization tests for TCA type inline/CSVhttp://forge.typo3.org/issues/876662019-02-06T14:32:59ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #87123 (Closed): Adjust modal window processing and RequireJS loadinghttp://forge.typo3.org/issues/871232018-12-11T12:46:19ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Feature #85051 (Rejected): Add possibility to deny setting cookies on client sidehttp://forge.typo3.org/issues/850512018-05-19T14:22:19ZOliver Haderoliver.hader@typo3.org
<p>In the scope of GDPR and ePrivacy regulations inside the EU it become required that users provide agreement before any cookies are set.<br />Since the TYPO3 core sets a couple of cookie automatically it is required to introduce an API that is capable of individually allow/deny cookies by individual handlers that might be provided by one or some 3rd party extensions.</p> TYPO3 Core - Bug #22002 (Closed): Add unit test concerning XML parsing of unwrapped entitieshttp://forge.typo3.org/issues/220022010-01-21T15:12:45ZOliver Haderoliver.hader@typo3.org
<p>Imagine a XML value like the following:<br />index.php?&id=13</p>
<p>Several PHP/libxml versions do not parse entities like "&amp;" anymore, thus this part has to be wrapped in a CDATA block. A setting in the install tool automatically adds this block for flexforms - $TYPO3_CONF_VARS['BE']['flexformForceCDATA'].</p>
<p>However, this unit test checks whether the used PHP version requires the CDATA setting.</p>
<p>(issue imported from #M13317)</p> TYPO3 Core - Feature #20521 (Closed): Add possibility to validate a string as regular expressionhttp://forge.typo3.org/issues/205212009-05-28T17:36:19ZOliver Haderoliver.hader@typo3.org
<p>If working with regular expression (regexp) defined by configuration as string it is handy to have a possibility to run a basic validation on this string.</p>
<p>(issue imported from #M11210)</p> TYPO3 Core - Bug #19559 (Closed): AdminPanel shows superfluous "Include file class.tx_whatever_pi...http://forge.typo3.org/issues/195592008-11-03T11:58:22ZOliver Haderoliver.hader@typo3.org
<p>The AdminPanel shows superfluous "Include file class.tx_whatever_pi1.php" messages even if the file was included before. That's not a real problem, since the file itself gets included by PHP's "include_once" and will be only loaded once. But the information in the AdminPanel can be improved.</p>
For USER_INT objects the flow is like the following:
<ul>
<li>cObj: push object information to $GLOBALS['TSFE']->config['INTincScript'] (with includeLibs configuration)</li>
<li>TSFE: post-process objects and load files of includeLibs configuration</li>
<li>TSFE: recall cObj->USER as "USER" object (not "USER_INT") anymore</li>
<li>cObj: includeLibs is found again and information of "File inclusions" is shown</li>
</ul>
<p>Solution:<br />a) remove includeLibs before passing again to cObj<br />b) track what files have been included before (but takes much longer)</p>
<p>(issue imported from #M9722)</p> TYPO3 Core - Feature #17434 (Closed): Allow more than one parent field pointing to the same child...http://forge.typo3.org/issues/174342007-07-04T14:23:46ZOliver Haderoliver.hader@typo3.org
<p>The following field configuration of a parent record in TCE is currently not possible:</p>
<p>'columns' => array(<br /> 'firstchildren' => array(<br /> 'config' => array(<br /> 'type' => 'inline',<br /> 'foreign_table' => 'tx_myext_child',<br /> 'foreign_field' => 'parent',<br /> ),<br /> ),<br /> 'secondchildren' => array(<br /> 'config' => array(<br /> 'type' => 'inline',<br /> 'foreign_table' => 'tx_myext_child',<br /> 'foreign_field' => 'parent',<br /> ),<br /> ),<br />),</p>
<p>The reason is, that with foreign_field the children are selected by the table and the uid in the field 'parent'. Thus, the children are not identified to with <em>field</em> in the parent record they belong.</p>
<p>The feature request is to have a new TCA property likle 'foreign_fieldfield' that defines a field on the child side storing the fieldname of the parent record creating the child.</p>
<p>The attached extension "test_required" reproduces this behaviour.</p>
<p>(issue imported from #M5897)</p>