Bug #84503
Updated by Oliver Hader about 6 years ago
h2. Short summary * regression in TYPO3 v7.6.25 and v8.7.11 when trying to log into the backend using a regular workflow (fill form, click login button) * basically affects Firefox (except macOS version) browsers - e.g. Chrom is not affected by this misbehavior h2. TYPO3 releases Updated TYPO3 versions 7.6.26 and 8.7.12 (to substitute 7.6.25 and 8.7.11) are planned to be released on Thursday, March 22nd, 2018. h2. Side note on RsaAuth System extension "rsaauth" provides a public/private key encryption mechanism to for encrypt user credentials that are submitted using an insecure channel (e.g. plain HTTP on port 80). In case a web site is using secure channels (e.g. HTTPS on port 443) the system extension "rsaauth" can be disabled completely in combination with changing the @loginSecurityLevel@ setting in the install tool for frontend and backend from @rsa@ to @normal@ - RsaAuth is superfluous in case the communication to the server is secured via TLS (HTTPS) already. In general it's suggested to use HTTPS instead of RsaAuth! h2. Explanation The fix for issue #76120 - which was targeted to work-around situations when a login form has two submit buttons with different meanings/actions - introduce a regression which lead to the situation that users could not login anymore into the TYPO3 backend. The mentioned regression was handled in issue #84253 which introduced a work-around for the TYPO3 backend part. A short summary what happened in the JavaScript part handling the login process: * extensions like sr_feuser_register combine different actions by using different name attributes on submit buttons in the same containing form element - in general using different endpoint actions would be suggested instead of combining the meaning in the same form * the mentioned first work-around change tries to preserve the name attribute of the clicked button to be send with the very same form - this was necessary since the button gets disabled once it was clicked (to prevent resubmission and clicking multiple times) - disabled form element are not delivered in the @application/x-www-form-urlencoded@ part of the HTTP message to the server * the change that introduced the first regression was focusing on button that has been clicked by checking the @:focus@ state of the button and tried to click that again - since the button already became disabled, it also cannot be clicked again and wont actually send the form contents to the server * the behavior basically affects FIrefox (excluding macOS versions, see below) ** Firefox does not support @click@ events on disabled form elements, see https://developer.mozilla.org/en-US/docs/Web/Events/click#Browser_compatibility - this applies e.g. to Edge as well ** several browsers set the @:focus@ state when clicking an element, except Firefox and Safari on macOS ** the combination of these criteria lead to the mentioned misbehavior and explain why e.g. Chrome is not affected, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus To streamline the behavior the following has to be done: * revert both changes, the one that introduced the regression and the other that fixed the regression in the backend scope * (optionally) re-implement the initial bug fix for #76120 without touching the backend part and only focussing carefully on the frontend part