TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-09-28T10:21:50ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102058 (New): Meta tags rendered as XHTMLhttp://forge.typo3.org/issues/1020582023-09-28T10:21:50ZOliver Haderoliver.hader@typo3.org
<pre>
<meta name="generator" content="TYPO3 CMS" />
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
<meta name="robots" content="index,follow" />
...
<meta property="og:image:type" content="image/png" />
<meta property="og:title" content="IN.DIE.musik e.V." />
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@InDieMusik" />
</pre>
<p><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/MetaTag/AbstractMetaTagManager.php#L226-L239">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/MetaTag/AbstractMetaTagManager.php#L226-L239</a></p>
<pre>
$metaTags[] = '<meta ' .
htmlspecialchars($nameAttribute) . '="' . htmlspecialchars($property) . '" ' .
htmlspecialchars($contentAttribute) . '="' . htmlspecialchars($propertyItem['content']) . '" />';
</pre> TYPO3 Core - Bug #102057 (New): W3C validator complains about base64 values in CSPhttp://forge.typo3.org/issues/1020572023-09-28T09:21:37ZOliver Haderoliver.hader@typo3.org
<p>From <a class="external" href="https://validator.w3.org/nu/">https://validator.w3.org/nu/</a></p>
<blockquote>
<p>Warning: Content-Security-Policy HTTP header: Bad content security policy: Invalid base64-value (should be multiple of 4 bytes: 54)</p>
</blockquote>
<p>From the specs at <a class="external" href="https://www.w3.org/TR/CSP3/#framework-directive-source-list">https://www.w3.org/TR/CSP3/#framework-directive-source-list</a></p>
<blockquote>
<p>; Nonces: 'nonce-[nonce goes here]'<br />nonce-source = "'nonce-" base64-value "'"</p>
<p>The base64-value grammar allows both base64 and base64url encoding. These encodings are treated as equivalant when processing hash-source values. Nonces, however, are strict string matches: we use the base64-value grammar to limit the characters available, and reduce the complexity for the server-side operator (encodings, etc), but the user agent doesn’t actually care about any underlying value, nor does it do any decoding of the nonce-source value.</p>
</blockquote>
<hr />
<p>For context, the used nonce value was <code>'nonce-GFsVtSG1EzqppYEFujbWjoMJS2r8FDH_Y8mRjRl-sKg9L0sLpQqsrA'</code></p>
<ul>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH_Y8mRjRl-sKg9L0sLpQqsrA</code> in base64web</li>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH/Y8mRjRl+sKg9L0sLpQqsrA</code> in base64 (shortened)</li>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH/Y8mRjRl+sKg9L0sLpQqsrA==</code> in base64 (complete, 56 chars, 56 mod 4 = 0)</li>
</ul> TYPO3 Core - Bug #101415 (New): Cannot localize page in backendhttp://forge.typo3.org/issues/1014152023-07-22T17:59:04ZOliver Haderoliver.hader@typo3.org
<p>(Actions performed as admin user)</p>
<p>Error message in JavaScript console:</p>
<pre>
Uncaught TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at InputTransformer.flattenObject (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:641)
at input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:770
at Array.reduce (<anonymous>)
at InputTransformer.flattenObject (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:649)
at InputTransformer.toSearchParams (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:481)
at AjaxRequest.withQueryArguments (ajax-request.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:352)
at Localization.localizeRecords (localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:6623)
at Object.callback (localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:5597)
at Wizard.runSlideCallback (wizard.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:3552)
flattenObject @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
(anonymous) @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
flattenObject @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
toSearchParams @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
withQueryArguments @ ajax-request.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
localizeRecords @ localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
(anonymous) @ localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
runSlideCallback @ wizard.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
</pre>
<p>The reason is, that in <code>localization.ts</code>, the corresponding <code>action</code> is still <code>null, since there are two @availableLocalizationModes</code> (<code>copy</code> and <code>translate</code>), but the handling just expects to have one...</p>
<pre>
<a href="#" class="btn btn-default btn-sm t3js-localize" title=""
data-page="[Translate to Dansk:] 404" data-has-elements="0"
data-allow-copy="1" data-allow-translate="1" data-table="tt_content"
data-page-id="6" data-language-id="1" data-language-name="Dansk">
...
Translate
</a>
</pre> TYPO3 Core - Bug #100904 (New): Fallback to script-src and style-srchttp://forge.typo3.org/issues/1009042023-05-20T11:24:22ZOliver Haderoliver.hader@typo3.org
<p>Using CSP in the wild still shows several browsers not supporting the <code>-attr</code> or <code>-elem</code> (CSP level 3) variants of <code>script-src</code> and <code>style-src</code> (CSP level 1). Therefore it seems to be required, to introduce an internal merge/fall-back possibility, but still keeping the specific <code>-attr</code> or <code>-elem</code> declarations for the future.</p>
<p>Thus, when instructed, the <code>-attr</code> or <code>-elem</code> declarations shall be merged into their parent <code>script-src</code> and <code>style-src</code> directives. The instruction might be different for each scope (backend, frontend, frontend-site).</p> TYPO3 Core - Bug #96435 (New): Apply rate limiter to mail formshttp://forge.typo3.org/issues/964352021-12-27T18:09:10ZOliver Haderoliver.hader@typo3.org
<p>In order to limit sending forms again and again (which can be automated e.g. by using Selenium or similar techniques), sending out a particular form should be rate-limited (available since TYPO3 v11).</p> TYPO3 Core - Bug #95725 (New): Title shown twice with pdfinfo using PDF/X fileshttp://forge.typo3.org/issues/957252021-10-21T18:44:48ZOliver Haderoliver.hader@typo3.org
<p>The following report has been sent to me via mail by Josef Sigritz, I'm just dumping it here:</p>
<hr />
<p>wir haben ein Problem mit dem FileContentParser der Indexed_Search: pdfinfo gibt bei PDF/X-Dateien zweimal den Title aus. Dadurch wird der eigentliche Title überschrieben.</p>
<p>Beispiel:<br />pdfinfo test.pdf</p>
<pre>
*Title: BAA010718_Broschüre_Chancen_bieten_V2.indd*
Creator: Adobe InDesign CC 13.0 (Macintosh)
Producer: Adobe PDF Library 15.0
CreationDate: Thu Feb 22 15:51:27 2018 CET
ModDate: Mon Mar 12 12:12:12 2018 CET
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 20
Encrypted: no
Page size: 595.276 x 841.89 pts (A4)
Page rot: 0
File size: 2292621 bytes
Optimized: yes
PDF version: 1.3
PDF subtype: PDF/X-3:2002
*Title: ISO 15930 - Electronic document file format for prepress digital data exchange (PDF/X)*
Abbreviation: PDF/X-3:2002
Subtitle: Part 3: Complete exchange suitable for colour-managed workflows (PDF/X-3)
Standard: ISO 15930-3
</pre>
<p>Verbesserungsvorschlag:<br />Klasse: typo3/typo3/sysext/indexed_search/Classes/FileContentParser.php, function splitPdfInfo</p>
<pre>
public function splitPdfInfo($pdfInfoArray)
{
$res = [];
if (is_array($pdfInfoArray)) {
foreach ($pdfInfoArray as $line) {
$parts = explode(':', $line, 2);
if (count($parts) > 1 && trim($parts[0])) {
if (!array_key_exists(strtolower(trim($parts[0])), $res)){
$res[strtolower(trim($parts[0]))] = trim($parts[1]);
}
$res[strtolower(trim($parts[0]))] = trim($parts[1]);
}
}
}
return $res;
}
</pre> TYPO3 Core - Feature #93390 (New): Integrate source file based integrity checkhttp://forge.typo3.org/issues/933902021-02-01T07:56:59ZOliver Haderoliver.hader@typo3.org
<ul>
<li>having signed(!) list of valid hashsums of core and extension files
<ul>
<li>being part core release process</li>
<li>being part of TER publication process</li>
</ul>
</li>
<li>system report comparing file hashes
<ul>
<li>detect modifications</li>
<li>detect additional files</li>
</ul></li>
</ul>
<p>This probably works for know locations, but cannot be applied directly to "arbitrary file storages" like /fileadmin/.</p> TYPO3 Core - Feature #91668 (New): Add system communication APIhttp://forge.typo3.org/issues/916682020-06-17T17:46:25ZOliver Haderoliver.hader@typo3.org
<p>A system communication API could be used to retrieve data from official typo3.org services or send back anonymous usage data in order to help understand TYPO3-use-cases much better.</p>
<a name="Scenarios"></a>
<h2 >Scenarios<a href="#Scenarios" class="wiki-anchor">¶</a></h2>
<ul>
<li>compare current TYPO3 version with latest TYPO3 version & warn about missing security updates</li>
<li>fetch and display vendor messages for selected topics - e.g. release updates, important security notifications, etc.</li>
<li>send anonymous usage data back to granted services (typo3.org or custom endpoints)</li>
</ul>
<a name="Requirements"></a>
<h2 >Requirements<a href="#Requirements" class="wiki-anchor">¶</a></h2>
<ul>
<li>non-blocking - most of the communication shall happen in the background or in the client only (AJAX)</li>
<li>HTTP requests need to provide as less information as possible (no referrers, no cookies, ...)</li>
<li>each used communication stream/channel must be opt-in - users or site admins have to subscribe</li>
</ul> TYPO3 Core - Bug #91572 (New): Streamline install tool API usagehttp://forge.typo3.org/issues/915722020-06-03T19:06:31ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #88613 (New): Replace ObjectStorage & LazyObjectStorage with symfony/collectionhttp://forge.typo3.org/issues/886132019-06-21T21:37:23ZOliver Haderoliver.hader@typo3.org
<p>For regular ObjectStorage deserialization most probably would work - however there are inconsitencies concerning object integrity due to ObjectStorage using spl_object_hash() internally. In a result it would not be possible to detach an object retrieved from repository from some deserialized ObjectStorage - basically uid should be used as identifier here which would turn ObjectStorage into EntityStorage. So, we could live with serialization of ObjectStorage.</p>
<p>For LazyObjectStorage things are getting more difficult since serialization of it would mean to serialize backreferences to parent object as well as DataMapper state, ObjectManager state and in the end class Reflection state - that turns out to be a massive collection of serialized data.</p>
<p>Thus, we experience most pain with LazyObjectStorage and its current implementation.</p> TYPO3 Core - Feature #87300 (New): Limit amount of concurrent user sessions for same userhttp://forge.typo3.org/issues/873002018-12-27T13:53:30ZOliver Haderoliver.hader@typo3.org
<p>TYPO3 allows to use multiple sessions per user which is a feature on the one hand, but could also be a security risk on the other. In order to enhance the scenario it should be possible to limit the amount of concurrent user sessions per user (or disable concurrent logins at all).</p>
<p>Behavior either can be configured for the whole system or (optionally) per user.</p> TYPO3 Core - Bug #86231 (New): Distinguish between free-mode localization and chained translationhttp://forge.typo3.org/issues/862312018-09-12T08:51:28ZOliver Haderoliver.hader@typo3.org
<p>Based on my note <a class="external" href="https://forge.typo3.org/issues/86141#note-5">https://forge.typo3.org/issues/86141#note-5</a> when analyzing the behavior</p>
<a name="TLDR"></a>
<h2 >TL;DR<a href="#TLDR" class="wiki-anchor">¶</a></h2>
<p>When skimming over the examples below, focus and compare the values in <code>l10n_parent</code> and realize that <code>l10n_source</code> is <strong>optional</strong>.</p>
<a name="Usage"></a>
<h2 >Usage<a href="#Usage" class="wiki-anchor">¶</a></h2>
<p>Localizations can be created using the graphical backend interface (e.g. page module) or by invoking direct commands to DataHandler [1]. Thus even if the page module is only valid for <code>tt_content</code> records, it does not prevent records from being translated or localized explicitly. That's why this analysis used <code>element</code> instead of <code>tt_conent</code> a pointer to a database table holding relevant records.</p>
<a name="Terminology"></a>
<h2 >Terminology<a href="#Terminology" class="wiki-anchor">¶</a></h2>
<a name="Connected-Mode"></a>
<h3 >Connected Mode<a href="#Connected-Mode" class="wiki-anchor">¶</a></h3>
<p>When translating elements, each element is bound to it's relative ancestor. This results into a chain (that can be used for language fallbacks etc.).<br />The following example illustrates that, <code>l10n_parent</code> always points to the initial record in default language, <code>l10n_source</code> points to it's relative translation ancestor - that's the record a new translation is based on. All records are connected in a chain.</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1, l10n_source=2
</pre>
<a name="Free-Mode"></a>
<h3 >Free Mode<a href="#Free-Mode" class="wiki-anchor">¶</a></h3>
<p>When localizing elements in free-mode, the previously mentioned translation chain is broken up, thus "free-mode localizaion elements" are in a specific language, but are not related to any relative ancestor and thus are idependent. The following example uses <code>element:3</code> as "free-mode localization", <code>l10n_parent</code> is set to <code>0</code>, but <code>l10n_source</code> still points to it's relative localization ancestor (just as information, not as a strict relation in like a "composition" [2] would have been).</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2
</pre>
<a name="The-Challenge"></a>
<h2 >The Challenge<a href="#The-Challenge" class="wiki-anchor">¶</a></h2>
<a name="Translation-from-existing-localization"></a>
<h3 >Translation from existing localization<a href="#Translation-from-existing-localization" class="wiki-anchor">¶</a></h3>
<p>It is possible, to create a new localization directly, that does not have a record in default language - or as alternative start a translation based on a "free-mode localization element".<br />The example shows, that the "English (Default)" record is now missing - the translation chain should(!) start with "French Translation" as first chain link. Since no record in default language s involved <code>l10n_parent</code> stay empty with <code>0</code>, only <code>l10n_source</code> point to their according relative ancestor records.</p>
<pre>
+ element:2 - French Translation - language:1, l10n_parent=0, l10n_source=1 # <- translation chain or free-mode localization?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2 # <- translation chain or free-mode localization?!
</pre>
<p>When comparing the "Franco-Canadian Translation" here to the one shown in the "Free Mode" section, it cannot be distinguished anymore, whether the record is part of a "translation chain" or has been created as "free-mode localization".</p>
<a name="The-information-in-l10n_source-is-not-mandatory"></a>
<h3 >The information in <code>l10n_source</code> is not mandatory<a href="#The-information-in-l10n_source-is-not-mandatory" class="wiki-anchor">¶</a></h3>
<p>Besides that, the information stored in the <code>l10n_source</code> field is optional and has to be configured in the control section of <code>$TCA</code> using the <code>translationSource</code> property. Thus, that information might not be available at all. The following examples show persisted results without having the <code>l10n_source</code> information.</p>
<a name="Connected-Mode-without-l10n_source"></a>
<h4 >Connected Mode without <code>l10n_source</code><a href="#Connected-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1 # <- part of a translation chain, which one?!
</pre>
<p>It is not possible anymore to determine at all, whether a record is part of a translation chain - since the relative ancestor is missing.</p>
<a name="Free-Mode-without-l10n_source"></a>
<h4 >Free Mode without <code>l10n_source</code><a href="#Free-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0 # <- translation chain or free-mode localization?!
</pre>
<p>It is (like in section "Translation from existing localization") not possible to distinguish between "connected translations" and "free-mode localizations".</p>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<p>[1]: DataHandler commands "localize" and "copyToLanguage": <a class="external" href="https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values">https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values</a><br />[2]: Association, Aggregation, Composition in UML: <a class="external" href="https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/">https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/</a></p> TYPO3 Core - Bug #81552 (New): Disable creating new inline child records if allowLanguageSynchron...http://forge.typo3.org/issues/815522017-06-12T13:14:29ZOliver Haderoliver.hader@typo3.org
<p><img src="http://forge.typo3.org/attachments/download/32533/81552.png" alt="" loading="lazy" /><br /><img src="http://forge.typo3.org/attachments/download/32538/81552_2.png" alt="" loading="lazy" /></p>
<p>If allowLanguageSynchronization is active for inline child elements, the "create new" buttons and any other interaction shall be disabled for localized parent records - since these child records. Otherwise there's the possibility to create inconsistent and non-synchronized scenarios.</p> TYPO3 Core - Bug #78849 (New): Show logged records of DatabaseWriter in ext:beloghttp://forge.typo3.org/issues/788492016-12-01T12:33:34ZOliver Haderoliver.hader@typo3.org
<p>Log entries that have been persisted using the logging-framework are not visualized in ext:belog.<br />The reason is, that the logging-framework uses different field names for the sys_log table that are not considered.</p> TYPO3 Core - Feature #33747 (New): Implement usort() and moveItemAt() in AbstractRecordCollectionhttp://forge.typo3.org/issues/337472012-02-07T21:22:01ZOliver Haderoliver.hader@typo3.org
<p>Current situation:</p>
<pre>
public function usort($callbackFunction) {
// TODO: Implement usort() method with TCEforms in mind
throw new RuntimeException('This method is not yet supported.', 1322545589);
}
public function moveItemAt($currentPosition, $newPosition = 0) {
// TODO: Implement usort() method with TCEforms in mind
throw new RuntimeException('This method is not yet supported.', 1322545626);
}
</pre>