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 - Bug #91572 (New): Streamline install tool API usagehttp://forge.typo3.org/issues/915722020-06-03T19:06:31ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #89414 (New): Document new search behavior in filelist and suggest wizardhttp://forge.typo3.org/issues/894142019-10-14T22:00:44ZOliver Haderoliver.hader@typo3.org
<ul>
<li><a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/61927">https://review.typo3.org/c/Packages/TYPO3.CMS/+/61927</a></li>
<li><a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/61929">https://review.typo3.org/c/Packages/TYPO3.CMS/+/61929</a></li>
</ul>
<p>new search syntax is</p>
<pre>"first aspect" second "third"</pre> TYPO3 Core - Task #89347 (New): Provide strong defaults for anchor noreferred/noopener attributehttp://forge.typo3.org/issues/893472019-10-04T12:02:37ZOliver Haderoliver.hader@typo3.org
<p>Issue <a class="issue tracker-2 status-5 priority-4 priority-default closed child" title="Feature: Add rel="noopener noreferrer" to links when target is set to _blank (Closed)" href="http://forge.typo3.org/issues/78488">#78488</a> introduced norefferer & noopener per default for external links, see<br /><a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/59194">https://review.typo3.org/c/Packages/TYPO3.CMS/+/59194</a></p>
<p>However there are scenarios where this has to be seen in context and scope of the website project:</p>
<a name="General"></a>
<h2 >General<a href="#General" class="wiki-anchor">¶</a></h2>
<ul>
<li><code>noopener</code> only has an effect of "opened" window contexts (e.g. <code>target="_blank"</code>)</li>
<li><code>noreferrer</code> might contradict tracking & analyzation on websites
<ul>
<li>e.g. "which site is has similar information" - good use of referrer in a scope similar to "LOD"
<ul>
<li><code>Referrer: https://typo3-website.org/resources/car-engines/abc</code> when opening <code>https://remote-vendor.com/cars/xyz</code></li>
</ul>
</li>
<li>e.g. "which site has similar problems" - bad use of referrer, when e.g. sensitive areas point public resources
<ul>
<li><code>Referrer: https://typo3-website.org/user-restricted-internal/product-abc-sucks</code> pointing to <code>https://remote-vendor.com/prodct-abc</code></li>
</ul></li>
</ul></li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>make settings configurable
<ul>
<li>TypoScript <code>typolink</code></li>
<li>Site Configuration anchor behavior</li>
</ul>
</li>
<li>default settings (when not having TypoScript or Site Configuration loaded - e.g. CLI context) should be strict <code>noopener noreferrer</code> (current scenario)</li>
<li>use <code>Referrer-Policy</code> HTTP header as site-wide default instead, use HTML attr to override the default behavior
<ul>
<li>different per site (frontend)</li>
<li>common for admin UI (backend)</li>
</ul></li>
</ul>
<a name="Side-note"></a>
<h2 >Side-note<a href="#Side-note" class="wiki-anchor">¶</a></h2>
There is a difference between TYPO3 backend and frontend as well. Basically
<ul>
<li>strict default for backend should be <code>noopener noreferrer</code></li>
<li>individual behavior for frontend as outlined in previous sections</li>
</ul> TYPO3 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 - Epic #87417 (New): Integrate proper Content Security Policy (CSP) handlinghttp://forge.typo3.org/issues/874172019-01-13T10:58:12ZOliver Haderoliver.hader@typo3.org
<p>In order to reduce risks of cross-site scripting in the TYPO3 backend proper CSP handling shall be integrated into the TYPO3 core. Just setting the headers is not enough since also reporting, management and adjustment of core components as well as 3rd party components (extensions) are required.</p>
<p>The functionality is outlined like this</p>
<ul>
<li>CSP management & configuration module (either on a site level or for whole TYPO3 installation)</li>
<li>CSP violation reporting endpoint in order to identify flaws and violations earlier (might be misconfiguration or vulnerability)</li>
<li>CSP manifest definition that allows 3rd party extensions to use resources of remote hosts (to be used in management module)</li>
<li>adjustment and refactoring of TYPO3 core components & guidelines for extension authors</li>
</ul> 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 - Task #85640 (New): Use context object in database restrictionshttp://forge.typo3.org/issues/856402018-07-25T10:46:41ZOliver Haderoliver.hader@typo3.org
In order to apply the existing <code>Context</code> object, its aspects need to be applied when executing queries using DBAL. This has possibly an impact on
<ul>
<li>Extbase QuerySettings (has to be checked)</li>
<li>QueryBuilder and applying restrictions</li>
</ul>
<p>By using and adapter, the <code>Context</code> object can be upgraded to be a <code>ContextBasedRestrictionContainer</code> which implements <code>QueryRestrictionContainerInterface</code> which keeps a local reference to the originating <code>Context</code> object in order to retrieve its aspects.</p> TYPO3 Core - Task #69966 (New): Integrate localization and fallback resolving in PlainDataResolverhttp://forge.typo3.org/issues/699662015-09-19T10:53:29ZOliver Haderoliver.hader@typo3.org
<p>PlainDataResolver is targeted to resolve relations based on a given context (workspaces, localization). The currently implementation is used only for workspaces in the TYPO3 backend. However, the resolving pipe should consider localization and localization fallbacks as well.</p>