TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-10-26T08:30:32ZTYPO3 Forge
Redmine TYPO3 Core - Task #102262 (New): Add CSP MutationMode::InheritStatic (or similar)http://forge.typo3.org/issues/1022622023-10-26T08:30:32ZOliver Haderoliver.hader@typo3.org
<p>From <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/80756/comments/83fac188_a7132447">https://review.typo3.org/c/Packages/TYPO3.CMS/+/80756/comments/83fac188_a7132447</a></p>
<blockquote>
<p>I would prefer we had some kind of "late static binding" extensions, that says: "whatever is changed on the ancestor sometime later, please inherit" <br />Maybe that could be "InheritStatic".<br />Anyway I'm still fine with this patch as is.</p>
</blockquote> TYPO3 Core - Task #100906 (New): Handle CSP violations in browser extensionshttp://forge.typo3.org/issues/1009062023-05-20T11:55:08ZOliver Haderoliver.hader@typo3.org
<a name="General"></a>
<h3 >General<a href="#General" class="wiki-anchor">¶</a></h3>
<ul>
<li><a class="external" href="https://csper.io/blog/csp-report-filtering">https://csper.io/blog/csp-report-filtering</a></li>
<li><a class="external" href="https://dropbox.tech/security/on-csp-reporting-and-filtering">https://dropbox.tech/security/on-csp-reporting-and-filtering</a></li>
<li><a class="external" href="https://github.com/nico3333fr/CSP-useful/tree/master/csp-wtf">https://github.com/nico3333fr/CSP-useful/tree/master/csp-wtf</a></li>
<li><a class="external" href="https://github.com/getsentry/sentry/blob/master/src/sentry/interfaces/security.py#L20">https://github.com/getsentry/sentry/blob/master/src/sentry/interfaces/security.py#L20</a></li>
<li><a class="external" href="https://github.com/jacobbednarz/go-csp-collector/blob/b3a8ff39e3835b3b9452898beb20677cee680dd0/csp_collector.go#L59">https://github.com/jacobbednarz/go-csp-collector/blob/b3a8ff39e3835b3b9452898beb20677cee680dd0/csp_collector.go#L59</a></li>
</ul>
<a name="Payloads"></a>
<h3 >Payloads<a href="#Payloads" class="wiki-anchor">¶</a></h3>
<code>{"blocked-uri":"inline","column-number":9,"disposition":"enforce","document-uri":"https:\/\/indiemusik-festival.de\/events\/festival-2023","effective-directive":"script-src-elem","line-number":33,"original-policy":"frame-src 'self' https:\/\/*.youtube-nocookie.com https:\/\/*.youtube.com https:\/\/*.vimeo.com https:\/\/instagram.com https:\/\/*.instagram.com; img-src 'self' https:\/\/*.ytimg.com https:\/\/*.vimeocdn.com data: https:\/\/instagram.com https:\/\/*.instagram.com; default-src 'self'; script-src 'self' 'nonce-XnDPuvTcc38QsmBT2aH5OLzK1Vv1G9l_HZZ-sioaqjJmVB2lpp7RXg' 'report-sample'; style-src-attr 'unsafe-inline' 'report-sample'; object-src 'none'; base-uri 'none'; style-src 'self' 'report-sample'; connect-src 'self' https:\/\/analytics.in-die-musik.de; script-src-elem 'self' 'nonce-XnDPuvTcc38QsmBT2aH5OLzK1Vv1G9l_HZZ-sioaqjJmVB2lpp7RXg' https:\/\/analytics.in-die-musik.de 'report-sample'; font-src 'self' data:; media-src 'self' https:\/\/cloud.in-die-musik.de; report-uri https:\/\/indiemusik-festival.de\/@http-reporting?csp=report&requestTime=1684526938506325","referrer":"","script-sample":"(function (NAVIGATOR, OBJECT) {\n\n if \u2026","source-file":"moz-extension","status-code":200,"violated-directive":"script-src-elem"}
</code>
<p>→ <code>"source-file":"moz-extension"</code><br />→ payload <code>(function (NAVIGATOR, OBJECT) { if </code><br />→ trigger <a class="external" href="https://github.com/EFForg/privacybadger/blob/ef6a2b38b2550e8805076b072645367c4e044a79/src/js/contentscripts/dnt.js#L23">https://github.com/EFForg/privacybadger/blob/ef6a2b38b2550e8805076b072645367c4e044a79/src/js/contentscripts/dnt.js#L23</a></p>
<hr />
<p>...</p> TYPO3 Core - Task #99046 (New): DOCS: Routing Troubleshooting Sectionhttp://forge.typo3.org/issues/990462022-11-10T11:39:03ZOliver Haderoliver.hader@typo3.org
<ul>
<li><a class="external" href="https://forge.typo3.org/issues/91530">https://forge.typo3.org/issues/91530</a>
<ul>
<li>describe consequences of using <code>PageType</code> decorator</li>
<li>concerning optional route variables (using <code>defaults</code>)</li>
</ul>
</li>
<li><a class="external" href="https://forge.typo3.org/issues/94585">https://forge.typo3.org/issues/94585</a>
<ul>
<li>describe consequences of using route without specific segment, e.g. <code>/{variable}</code></li>
<li>suggest to use specific segment, e.g. <code>/show/{variable}</code></li>
</ul>
</li>
<li><a class="external" href="https://forge.typo3.org/issues/90959#note-3">https://forge.typo3.org/issues/90959#note-3</a>
<ul>
<li>describe consequences of ambiguity</li>
</ul></li>
</ul> TYPO3 Core - Task #95559 (New): Make authentication warnings configurablehttp://forge.typo3.org/issues/955592021-10-11T10:42:26ZOliver Haderoliver.hader@typo3.org
<p>Following <code>TYPO3_CONF_VARS</code> should be configurable:</p>
<ul>
<li><code>['BE']['warning_email_addr']</code> (possible already)</li>
<li><code>['BE']['warning_period']</code> (new, time in seconds >= 0, 0 means always)</li>
<li><code>['BE']['warning_max']</code> (new, integer >= 0, 0 means always)</li>
</ul> TYPO3 Core - Task #91703 (New): Add configuration guard for ambiguous literals in route pathshttp://forge.typo3.org/issues/917032020-06-23T23:57:56ZOliver Haderoliver.hader@typo3.org
<pre>
routePath: '/{value__value}/{other__}'
_arguments:
value__value: 'value/value'
other__: 'other__'
</pre>
<p>Given URL parameters would look like <code>&value[value]=a&other__=b</code>.<br />Literal <code>__</code> using as delimiter in <code>VariableProcessor</code>, see <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/9.5/typo3/sysext/core/Classes/Routing/Enhancer/VariableProcessor.php#L24">https://github.com/TYPO3/TYPO3.CMS/blob/9.5/typo3/sysext/core/Classes/Routing/Enhancer/VariableProcessor.php#L24</a></p>
<ul>
<li>add test-cases for those scenarios</li>
<li>adjust implementation, add guards based on findings</li>
</ul> TYPO3 Core - Task #91702 (New): Evaluate possibility for optional route partshttp://forge.typo3.org/issues/917022020-06-23T23:53:09ZOliver Haderoliver.hader@typo3.org
<p>The following would lead to URL parameters like <code>&value=abc&optional=</code></p>
<pre>
routerPath: '{value}/{optional}'
defaults:
optional: ''
</pre>
<p>The desired behavior would be to not expose the URL parameter <code>optional</code> at all, thus only having <code>&value=abc</code>.</p>
<pre>
routerPath: '{value}/{optional}'
defaults:
optional: null
</pre>
<p>This example is untested - in case it works already, cool.</p> TYPO3 Core - Task #91283 (New): Integrate HTTP Sec-Fetch header policyhttp://forge.typo3.org/issues/912832020-05-03T20:08:27ZOliver Haderoliver.hader@typo3.org
<p>Example headers:</p>
<ul>
<li>HTTP fetch
<ul>
<li>HTTP_SEC_FETCH_DEST: "empty" </li>
<li>HTTP_SEC_FETCH_MODE: "cors" </li>
<li>HTTP_SEC_FETCH_SITE: "same-origin"</li>
</ul></li>
</ul>
<ul>
<li>IFRAME fetch
<ul>
<li>HTTP_SEC_FETCH_DEST: "iframe" </li>
<li>HTTP_SEC_FETCH_MODE: "navigate" </li>
<li>HTTP_SEC_FETCH_SITE: "cross-site"</li>
</ul></li>
</ul>
<p>Resources:</p>
<ul>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest</a></li>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site</a></li>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-User</a></li>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode</a></li>
</ul>
<hr />
<p>Integrate <code>RequestPolicy</code> and <code>FetchPolicy</code></p>
<pre>
$requestPolicy = (new RequestPolicy())
->withFetchPolicy((new FetchPolicy())
->withAllowedAbsence(bool)
->withFetchDest(string[])
->withFetchSite(string[])
->withFetchUser(string[])
->withFetchMode(string[])
);
</pre> TYPO3 Core - Task #90995 (New): Integrate Cross-Origin-Opener-Policy HTTP header in backendhttp://forge.typo3.org/issues/909952020-04-10T13:33:39ZOliver Haderoliver.hader@typo3.org
<pre>
Cross-Origin-Opener-Policy: same-site
</pre>
<a name="References"></a>
<h3 >References<a href="#References" class="wiki-anchor">¶</a></h3>
<ul>
<li><a class="external" href="https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit">https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit</a></li>
<li><a class="external" href="https://www.chromestatus.com/feature/5432089535053824">https://www.chromestatus.com/feature/5432089535053824</a></li>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy</a></li>
</ul> 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 - Epic #84920 (New): Provide generic context based data retrieval APIhttp://forge.typo3.org/issues/849202018-05-03T14:50:35ZOliver Haderoliver.hader@typo3.org
<p>In order to avoid the requirement of specific knowledge of TYPO3 persistence behavior, such as localization or workspaces, a generic API to retrieve data shall be provided.</p>
The functional relies on these base parameters:
<ul>
<li>context (language, workspace)</li>
<li>permissions (pages, tables, fields, ..., context permissions)</li>
<li>optional behavior (language fallback, individual handling)</li>
</ul>
Basic functionality:
<ul>
<li>retrieve specific entities for the given base parameters (e.g. languages & workspaces resolved automatically)</li>
<li>retrieve any relational entities (children) for the given base parameters (not caring whether 1:n inline or m:n group/db has been defined)</li>
</ul>
Extended functionality:
<ul>
<li>retrieve data based on individual/custom query (fields, constraints, sorting)</li>
<li>retrieve data based on GraphQL query</li>
</ul> TYPO3 Core - Epic #84918 (New): Streamline Permission Layerhttp://forge.typo3.org/issues/849182018-05-03T14:41:43ZOliver Haderoliver.hader@typo3.org
<p>Concerning data handling and persistence, basically only the backend context is considered (in DataHandler, PageLayoutView et al). General permission handling in Extbase and other frontend related implementation is only implemented on the visibility of pages and frontend user groups.</p>
<p>In order to overcome these differences. Permission handling has to be generalized and used in affected components.<br />For instance as an impact, DataHandler does not rely on a BackendUserAuthentication (BE_USER) instance anymore, but on a generic Permission definition that can be used in backend and frontend context.</p> TYPO3 Core - Story #84917 (New): Make use of schema definition & relationship layerhttp://forge.typo3.org/issues/849172018-05-03T14:36:29ZOliver Haderoliver.hader@typo3.org
<ul>
<li>DataHandler, RelationHandler, DataMapProcessor</li>
<li>Extbase DataMapFactory, Storage Backend</li>
<li>FormEngine DataProviders, Containers</li>
<li>RootlineUtility</li>
</ul>
<p>... and more ...</p> TYPO3 Core - Story #84916 (New): Provide generic entity relationship modelhttp://forge.typo3.org/issues/849162018-05-03T14:30:00ZOliver Haderoliver.hader@typo3.org
<p>Expected goal</p>
<pre>
$contentSchemaDefinition = (new SomeService)->getSchemaDefinition('tt_content');
$fileReferenceSchemaDefinition = (new SomeService)->getSchemaDefinition('sys_file_reference');
var_dump($contentSchemaDefinition->getProperty('media')->getRelations());
var_dump($fileReferenceSchemaDefinition->getProperty('uid_foreign')->getRelations());
</pre>
<p>might output something like</p>
<pre>
# relations for tt_content.media
+ ActiveRelation: schemaName "sys_file_reference"
</pre>
<pre>
# relations for sys_file_reference.uid_foreign
+ PassiveRelation: schemaName "tt_content", propertyName: "image"
+ PassiveRelation: schemaName "tt_content", propertyName: "media"
+ PassiveRelation: schemaName "tt_content", propertyName: "assets"
</pre>
<p>Currently the "opposite usage" for relations is not explicitly known. In order to enhance look ups this information should be cached along with the plain schema definition (e.g. TCA).</p> TYPO3 Core - Story #84915 (New): Provide generic entity schema definitionhttp://forge.typo3.org/issues/849152018-05-03T14:19:06ZOliver Haderoliver.hader@typo3.org
<p>Expected goal</p>
<pre>
$factory = new TcaSchemaDefinitionFactory($GLOBALS['TCA']);
$schemaDefinition = $factory->buildForTable('tt_content');
$service = new SchemaDefinitionService();
$mediaProperty = $schemaDefinition->getProperty('media');
$service->isRelational(mediaProperty);
if ($service->getRelationType($mediaProperty) === Relation::TYPE_ONE_TO_MANY_COMPOSITION)) { ... }
</pre>
<p>The API above can still change. Besides that Extbase <code>DataMapFactory</code> could be considered as foundation as well.</p> TYPO3 Core - Epic #84914 (New): Streamline entity configuration layerhttp://forge.typo3.org/issues/849142018-05-03T14:08:35ZOliver Haderoliver.hader@typo3.org
<p>Entity configuration in TYPO3 is done by using TCA (table configuration array). Currently the interpretation of e.g. "what is a 1:n composition (IRRE)" is spread over multiple locations - most importantly to mention are DataHandler, Extbase and FormEngine - but there are much more.</p>
<p>In order to avoid individual (and possible) different interpretation of entity definitions and features and generic configuration shall be introduce to provide access to the the semantics of TCA and FlexForm data structures.</p>