TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-11-16T05:26:57ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102377 (Resolved): Backend requests are cached (and used) within 1s timeframehttp://forge.typo3.org/issues/1023772023-11-16T05:26:57ZBenjamin Franzkeben@bnf.dev
<p>Backend responses must never be cached. The Cache-Control instruction "must-revalidate" implicitly enables<br />caching in order to possibly reuse a response. While that could only happen when two requests to the same URL are<br />invoked withing one second (because the browsers `If-Modified-Since` header and our `Last-Modified` header<br />do match, causing the webserver to issue a 304 response), that is certainly possible in CI setups or fast user clicks.</p>
<p>Nightly runs (and new CI) caught following CSP errors that happended because a previous request to the same backend URL<br />was tried to be reused.<br />That means the browser sends a `If-Modified-Since` header, the server compares that to our <code>Last-Modified</code> header and because those match for 1s (given times on server and client are equal), the server responds with a 304 response and new CSP headers.</p>
<p>Now, the client uses those new CSP headers on the old (cached) content, causing CSP errors.</p>
<p>Log from a previous nightly: <a class="external" href="https://git.typo3.org/typo3/CI/cms/-/jobs/2719694">https://git.typo3.org/typo3/CI/cms/-/jobs/2719694</a></p>
<pre>
1) TemplateCest: Open the TypoScript Object Browser and search a keyword.
Test Acceptance/Application/Template/TemplateCest.php:searchInTypoScriptActive
Step Use existing session "admin"
Fail Found following JavaScript errors in the browser console:
01:12:43.964 SEVERE - http://web/typo3/index.php 24 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-q-0rXT6ndm1d4k1PB_skehGuei9NU4RmepZIoI0jaD4t4mptySRwtg' 'report-sample'". Either the 'unsafe-inline' keyword, a hash ('sha256-mOe1j2nA39ZHBa9vuj8vjm6s1j12BoBxmU5pq+c8myY='), or a nonce ('nonce-...') is required to enable inline execution.
01:12:43.965 SEVERE - http://web/typo3/index.php 28 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-q-0rXT6ndm1d4k1PB_skehGuei9NU4RmepZIoI0jaD4t4mptySRwtg' 'report-sample'". Either the 'unsafe-inline' keyword, a hash ('sha256-eYBX9tiv0eShqtr6+0ybc98Tpn+++UDyS8IavaWnnig='), or a nonce ('nonce-...') is required to enable inline execution.
01:12:43.985 SEVERE - http://web/typo3/sysext/core/Resources/Public/JavaScript/java-script-item-handler.js?1699903243 12:137 Uncaught TypeError: Failed to resolve module specifier '@typo3/core/java-script-item-processor.js'
Scenario Steps:
1. $I->useExistingSession("admin") at Acceptance/Application/Template/TemplateCest.php:26
Artifacts:
Png: /builds/typo3/CI/cms/typo3/sysext/core/Tests/../../../../typo3temp/var/tests/AcceptanceReports/TYPO3.CMS.Core.Tests.Acceptance.Application.Template.TemplateCest.searchInTypoScriptActive.headless.fail.png
Html: /builds/typo3/CI/cms/typo3/sysext/core/Tests/../../../../typo3temp/var/tests/AcceptanceReports/TYPO3.CMS.Core.Tests.Acceptance.Application.Template.TemplateCest.searchInTypoScriptActive.headless.fail.html
FAILURES!
Tests: 36, Assertions: 162, Failures: 1.
</pre> TYPO3 Core - Story #101904 (Accepted): CKEditor5 UIhttp://forge.typo3.org/issues/1019042023-09-13T03:56:05ZBenjamin Franzkeben@bnf.dev
<p>Tracker for UI related CKEditor5 bugs or tasks.</p> TYPO3 Core - Bug #101684 (Under Review): <typo3-backend-icon> changed to inline element in TYPO3 v12http://forge.typo3.org/issues/1016842023-08-15T07:32:44ZBenjamin Franzkeben@bnf.dev
<p>Expect: <typo3-backend-icon> should render as in TYPO3 v11</p> TYPO3 Core - Bug #99590 (Closed): Accordion in image processing environment test not visiblehttp://forge.typo3.org/issues/995902023-01-18T09:09:02ZBenjamin Franzkeben@bnf.dev
<p>Current output:</p>
<p><img src="http://forge.typo3.org/attachments/download/37323/panel-missing.png" alt="" loading="lazy" /></p>
<p>Expected output:</p>
<p><img src="http://forge.typo3.org/attachments/download/37322/panel-expected.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #97301 (Closed): Avoid global jQuery usage in RTE link wizardhttp://forge.typo3.org/issues/973012022-04-05T11:52:37ZBenjamin Franzkeben@bnf.dev
<p>The global variable $ (window.$) has been removed with <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Remove global jquery object window.$ in TYPO3 Backend (Closed)" href="http://forge.typo3.org/issues/97243">#97243</a>.<br />This caused the RTE link wizard to fail with a JavaScript<br />error as $.isEmptyObject is used in typo3link.js.</p> TYPO3 Core - Bug #96978 (Closed): Backend "Stay logged in" button does refresh the login-sessionhttp://forge.typo3.org/issues/969782022-02-20T13:50:53ZBenjamin Franzkeben@bnf.dev
<p><strong>Steps to reproduce:</strong></p>
<p>1. Set <code>$GLOBALS['TYPO3_CONF_VARS']['BE']['sessionTimeout']</code> to <code>70</code>.<br />2. Login via /typo3/<br />3. Wait 60 seconds for the login-refresh-popup to occur<br />4. Click the "Stay logged in" button<br />5a Wait 10 seconds and click on a module => A redirect to the login screen will appear<br />5b Wait another 60 seconds => A password-box will appear because the session has not been updated.</p>
<p><strong>Description:</strong><br />For unknown reasons the /ajax/login/refresh<br />route has never been used (all the way back to v6),<br />to request a session timeout update.</p>
<p>Instead the route /ajax/login/timedout, <strong>without</strong> the<br />skipSessionUpdate=1 parameter has been used to<br />refresh an existing session.</p>
<p>With the introducting of configurable loute parameters<br />in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Move skipSessionUpdate values to AjaxRoutes config (Closed)" href="http://forge.typo3.org/issues/81409">#81409</a> this inconsitency wasn't noticed and the<br />skipSessionUpdate parameter has been moved into the<br />route-configuration, which meant /ajax/login/timedout was<br />always called with skipSessionUpdate=1,<br />even as result of the "Stay logged in" button, where<br />a session update was intended.</p>
<p>Use the dedicated /ajax/login/refresh route<br />in order to actually refresh the session.</p> TYPO3 Core - Bug #95972 (Closed): BackendUserAuthentication uses empty() to check for array valueshttp://forge.typo3.org/issues/959722021-11-15T09:26:16ZBenjamin Franzkeben@bnf.dev
<p>empty returns true, if an array key is set, e.g. to 0.</p> TYPO3 Core - Bug #93233 (Closed): Backend Group Comparison is brokenhttp://forge.typo3.org/issues/932332021-01-06T15:46:40ZBenjamin Franzkeben@bnf.dev
<pre>
(1/1) Error
Typed property TYPO3\CMS\Core\Authentication\AbstractUserAuthentication::$userSession must not be accessed before initialization
in /home/ben/src/TYPO3.CMS/typo3/sysext/core/Classes/Authentication/AbstractUserAuthentication.php line 1012
* @return mixed
*/
public function getSessionData($key)
{
return $this->userSession->get($key);
}
</pre> TYPO3 Core - Bug #93045 (Closed): 500 vs 503 error handling is not consistenthttp://forge.typo3.org/issues/930452020-12-10T07:48:04ZBenjamin Franzkeben@bnf.dev
<p>For 5xx status code we have two different cases right now
* configuration errors, which need to respond with 500
* maintenance mode, which is a 503 response</p>
<p>In 10.4.10 always 500 is returned, in master and 10.4 branch currently 503. This should be streamlined.</p>
<p>Also the 500 or 503 site error handler in maintenace middleware isn't invoked as the maintenace mode middleware is executed before the site resolver middleware.</p> TYPO3 Core - Bug #91074 (Rejected): typo3conf/ folder is not created when using a custom app-dir ...http://forge.typo3.org/issues/910742020-04-17T01:15:10ZBenjamin Franzkeben@bnf.dev
<p>In composer mode in composer.json:</p>
<pre><code>"extra": {<br /> "typo3/cms": {<br /> "app-dir": "custom",<br /> "web-dir": "public" <br /> }<br /> },</code></pre>
<p>In this case Environment::$projectPath would be /path/to/root/custom and Environment::$publicPath would be /path/to/root/public.</p>
<p>The typo3conf folder is then generated in /path/to/root/custom/typo3conf instead of /path/to/root/public/typo3conf.</p>
<p>This is actually by accident, because "custom" and "public" have the same length.<br />Reason is the code in <a class="external" href="https://git.typo3.org/Packages/TYPO3.CMS.git/blob/9fb677f6f3b3a1cd584b9ef183b35da771d3e25d:/typo3/sysext/install/Classes/FolderStructure/DefaultFactory.php#l134">https://git.typo3.org/Packages/TYPO3.CMS.git/blob/9fb677f6f3b3a1cd584b9ef183b35da771d3e25d:/typo3/sysext/install/Classes/FolderStructure/DefaultFactory.php#l134</a><br /><pre>
$publicPath = substr(Environment::getPublicPath(), strlen(Environment::getProjectPath())+1);
</pre><br />which tries to substract the project path from the public path, while assuming that project path is an ancestor, which results in a public path <code>""</code> to be calculate.<br />The result should rather be <code>"../public"</code>.</p>
<p>We should rather generate a relative path and adapt the FolderStructur Factory to handle relative paths, include partent dots ("..").</p> TYPO3 Core - Bug #89873 (Closed): backend:lock/backend:unlock are not longer available as schedul...http://forge.typo3.org/issues/898732019-12-06T10:12:05ZBenjamin Franzkeben@bnf.dev
<p><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Tasks backend:lock & backend:unlock most not be schdulable (Closed)" href="http://forge.typo3.org/issues/89387">#89387</a> dropped the support with the patch in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/61938">https://review.typo3.org/c/Packages/TYPO3.CMS/+/61938</a><br />The reason was to fix execution from the backend.</p>
<p>The schedulers <strong>primary</strong> task is to <strong>schedule</strong> tasks, not to execute them from the backend.<br />The backend-execution is only an additional functionality, which is available because it's sometime handy for manual tasks/testing.<br />We shouldn't mark commands as non-schedulable when scheduling them is a perectly valid usecase.</p> TYPO3 Core - Bug #86383 (Closed): adminpanel ConfigurationService calls getTSConfig in a deprecat...http://forge.typo3.org/issues/863832018-09-26T08:45:05ZBenjamin Franzkeben@bnf.dev
<p>Since <a class="external" href="https://review.typo3.org/56968">https://review.typo3.org/56968</a> handing over arguments to getTSConfig() is deprecated.<br />That means the following code logs a deprecation warning:</p>
<p><code>$this->mainConfiguration = $this->getBackendUser()->getTSConfig('admPanel')['properties'];</code></p> TYPO3 Core - Bug #86372 (Closed): CacheManager 'assets' cache is not configurable in ext_localcon...http://forge.typo3.org/issues/863722018-09-25T14:39:41ZBenjamin Franzkeben@bnf.dev
<p>Since commit <a class="external" href="https://review.typo3.org/c/54020/">https://review.typo3.org/c/54020/</a> + followup <a class="external" href="https://review.typo3.org/54061">https://review.typo3.org/54061</a> (released only in v9) it is no longer possible to configure the 'assets' cache in ext_localconf.php files.</p>
<p>The IconRegisty is loaded in backend mode and reads the configuration (caches from 'assets') during object construction.<br />IconRegistry is usually instantiated during ext_localconf.php (due to extensions registering icons),<br />and therefore create's the 'assets' cache during ext_localconf.php loading.</p>
<p>After CacheManager has created the assets cache once, it will never be recreated again,<br />when the final configuration is set, after all ext_localconf.php files have been loaded.</p> TYPO3 Core - Task #83953 (Closed): Inject the PackageManager into the DependencyResolverhttp://forge.typo3.org/issues/839532018-02-17T18:58:36ZBenjamin Franzkeben@bnf.devTYPO3 Core - Bug #78719 (Closed): Backend Login ignores redirect_urlhttp://forge.typo3.org/issues/787192016-11-16T15:03:24ZBenjamin Franzkeben@bnf.dev
<p>The commit 9099b64c (<a class="external" href="http://review.typo3.org/39234">http://review.typo3.org/39234</a>) introduced a new form API, and forgot to pass the GET parameter 'redirect_url' into the login template, the hidden input field is never filled.</p>
<p>That means redirect_url works for already logged-in users, but not if the user has to login first.</p>