TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-08-06T22:07:54ZTYPO3 Forge
Redmine TYPO3 Core - Task #28805 (Closed): Refactor query cache to make use of the new caching framework ...http://forge.typo3.org/issues/288052011-08-06T22:07:54ZHelmut Hummeltypo3@helhum.io
<p>The caching framework has been streamlined. Registering caches for extensions and fetching the cache is much easier now.<br />Refactor the query cache handling to reflect this change.</p> TYPO3 Core - Bug #28760 (Closed): Colors not selectable in table properties with IE 7 or 8http://forge.typo3.org/issues/287602011-08-04T16:12:21ZHelmut Hummeltypo3@helhum.io
<p>When having many colors defined (see: <a class="external" href="http://forge.typo3.org/attachments/15652/tsconfig.txt">http://forge.typo3.org/attachments/15652/tsconfig.txt</a>), it is only possible to select one of the first colors (foreground or background). If a color at the end of the list is selected, nothing happens.</p> TYPO3 Core - Bug #27935 (Closed): Exclude E_DEPRECATED form exceptional errorshttp://forge.typo3.org/issues/279352011-07-07T10:25:16ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />When an extension uses deprecated PHP functions with PHP 5.3, TYPO3 throws an exception because E_DEPRECATED is not excluded in the list of exceptional errors</p>
<p>Solution:<br />Add E_DEPRECATED to this list.</p> TYPO3 Core - Bug #27809 (Closed): API method persistTokens has been removed after refactoringhttp://forge.typo3.org/issues/278092011-07-02T14:36:07ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />After the heavy refactoring of the formprotection framework (<a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Essential form protection tokens are dropped when beeing logged in for a "long" time (Closed)" href="http://forge.typo3.org/issues/25359">#25359</a>) the public method persitTokens() has been removed, because was not needed any more.<br />Solution:<br />Since this has been a public API method, some extensions could have used it, so we need to introduce it again to avoid a fatal error for these extensions.</p> TYPO3 Core - Bug #25359 (Closed): Essential form protection tokens are dropped when beeing logged...http://forge.typo3.org/issues/253592011-03-20T16:46:18ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />The backend form protection uses the session data field to store created tokens. Since this database field has a certain size, the framework starts dropping tokens, when it holds a certain amount of tokens.</p>
<p>When doing so, it is very likely that tokens which are seldom replaced (like the ExtDirect token or the clear cache tokens) will be dropped, resulting in token validation error messages</p>
<p>Solution:<br />I suggest to abandon the extra security feature of having unique tokens, because it turned out to add a complexity which is almost impossible to handle</p>
<p>(issue imported from #M17991)</p> TYPO3 Core - Bug #24972 (Closed): Improve error handling in ExtDirect routerhttp://forge.typo3.org/issues/249722011-02-06T18:35:15ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />Even if something goes wrong in a ExtDirect request, the request gets processed, which lead to unexpected results.</p>
<p>Solution:<br />Do not process the request, but just return the error message instead.</p>
<p>Note:<br />The current behavior is especially annoying after the addition of the CSRF protection, because in case of an invalid request, a security token error message is sent, which is wrong.</p>
<p>(issue imported from #M17500)</p> TYPO3 Core - Bug #24970 (Closed): The refresh login dialogue is shown even if the session already...http://forge.typo3.org/issues/249702011-02-06T13:03:55ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />There are several reasons why a backend session can expire. If this happens, the refresh login dialogue is shown for 30 seconds giving the user the option to "stay logged in" or "log out". But in case the session is already expired, clicking "stay logged in" does not have an effect an only shows the dialogue again with reset counter.</p>
<p>Solution:<br />If the session is already expired, directly show the password dialogue.</p>
<p>Note:<br />This can be easily tested by deleting the be_typo_user cookie. Without the patch the progress bar is shown, with the patch you will see the password dialogue directly</p>
<p>(issue imported from #M17498)</p> TYPO3 Core - Bug #24962 (Closed): After introducing the locking in #24790 no CSRF token will ever...http://forge.typo3.org/issues/249622011-02-04T19:52:27ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />After introducing the locking in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Form protection tokens get lost because of a race condition when persisting tokens (Closed)" href="http://forge.typo3.org/issues/24790">#24790</a>, fetching the probably updated token array and merging this with the token array of the current request, all tokens that have been unset during this request are again added to the array (they are present in the fetched array of tokens).</p>
<p>Solution:<br />Keep track which tokens are added and deleted during the request and update the token array accordingly.</p>
<p>Note:<br />Since we now know if changes are made to the token array during one request, we could simply skip the locking and persisting, which saves quite some time for modules that do not create or validate tokens (which most modules do not do).</p>
<p>(issue imported from #M17490)</p> TYPO3 Core - Bug #24815 (Closed): Saving extension configuration failshttp://forge.typo3.org/issues/248152011-01-25T20:58:02ZHelmut Hummeltypo3@helhum.io
<p>This has already been reported here:<br /><a class="external" href="http://forge.typo3.org/issues/12455">http://forge.typo3.org/issues/12455</a></p>
<p>Moving the discussion to mantis to have all things in one place.</p>
<p>Original Description:<br />When trying to save the modified configuration of an extension, I get a message "Saving settings.." and eventually a flash message saying "Configuration was saved". Then pops up a Windows download dialogue about ajax.php.</p>
<p>The configuration changes were NOT saved.</p>
<p>The Backend log says: "Core: Error handler (BE): PHP Warning: array_pop() [<a href='function.array-pop'>function.array-pop</a>]: The argument should be an array in /.../t3lib/extjs/class.t3lib_extjs_extdirectrouter.php line 90"</p>
<p>(issue imported from #M17315)</p> TYPO3 Core - Bug #24809 (Closed): Rename the t3lib_formprotection_Factory class to t3lib_formprot...http://forge.typo3.org/issues/248092011-01-25T18:40:38ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />The formprotection factory class is currently named "t3lib_formprotection_Factory". This class however will do a bit more as a factory after <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Login/ Logout was not possible after introducing the locking in #24790 (Closed)" href="http://forge.typo3.org/issues/24805">#24805</a> is committed.</p>
<p>Additionally t3lib_formprotection::get() looks much more readyble to me than t3lib_formprotection_Factory::get()</p>
<p>Solution:<br />Change the name</p>
<p>(issue imported from #M17309)</p> TYPO3 Core - Bug #24805 (Closed): Login/ Logout was not possible after introducing the locking in...http://forge.typo3.org/issues/248052011-01-25T17:46:09ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />The backend formprotection relies on the possibility to store the tokens in the user session. This is not the case, if a user did not yet login (the login screen). Since the login screen also uses the template object and the persistToken calls were moved to this place, we need do decide whether to validate and store tokens or not.</p>
<p>Solution:<br />Check if we have a valid BE_USER session and if not provide a dummy object, which implements the same interface.</p>
<p>(issue imported from #M17305)</p> TYPO3 Core - Bug #24790 (Closed): Form protection tokens get lost because of a race condition whe...http://forge.typo3.org/issues/247902011-01-25T10:30:47ZHelmut Hummeltypo3@helhum.io
<p>Problem:</p>
<p>If two (or more) scripts are executed (almost) at the same time, both scripts retrieve the same token array from the session. Both scripts will create new tokens independently. The script that is executed last will overwrite the tokens generated by the first script.</p>
<p>Solution:<br />Before writing all tokens back to the session we need to retrieve the current tokens from the session again and lock this for one process only.</p>
How to test:
<ul>
<li>Apply the test patch</li>
<li>Reload the backend</li>
<li>Go to file list module and wait until both frames loaded</li>
<li>hover over the help icon in navigation frame</li>
</ul>
<p>(issue imported from #M17289)</p> TYPO3 Core - Bug #24786 (Closed): Formprotection persistToken method is called too often, causing...http://forge.typo3.org/issues/247862011-01-25T03:47:39ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />To asure that in all cases the tokens get persisted, I added the persistToken call way too often</p>
<p>Solution:<br />Remove most of the calls and add one in template->endPage instead, since this is a central exit point for all modules.<br />Thanks for Steffen Kamper for the idea.</p>
<p>Note: A few places are left, where the template object is not used, thus the persist method needs to be called there.</p>
<p>(issue imported from #M17284)</p> TYPO3 Core - Bug #24713 (Closed): The unit test for t3lib_formprotection_BackendFormProtection is...http://forge.typo3.org/issues/247132011-01-21T22:13:14ZHelmut Hummeltypo3@helhum.io
<p>Problem:<br />After changing the flash messages for the form protection tobe stored in the session, the unit test is broken.</p>
<p>Solution:<br />I broke it, I fix it ;)<br />For this test a user object is needed that mocks the session storage</p>
<p>(issue imported from #M17201)</p> TYPO3 Core - Bug #24456 (Closed): Information disclosure during backend loginhttp://forge.typo3.org/issues/244562011-01-03T00:35:39ZHelmut Hummeltypo3@helhum.io
<p>In case a wrong username is submitted other HTTP headers are sent, than<br />in case only the password is wrong. This provides an attacker more<br />information than intended.</p>
<p>I tracked down this problem to the various session_start() calls, which<br />also send HTTP headers by default. If the submitted username exists, a<br />php session is started to get the challange out of the session<br />(compareUident()). This sends out some HTTP headers which will then<br />partly be overridden by header() calls (sendNoCacheHeaders()) with the<br />same HTTP headers (both happening in t3lib_userauth).</p>
<p>OTRS: 2011010210000017<br />Reporter: Sebastian Schinzel<br />(issue imported from #M16894)</p>