TYPO3 Core

Maybe related to #20774 which suggests patches that don't seem to be in the current version of "saltedpasswords" and "setup" system extensions.

Quick (and dirty) fix: comment out lines 20 & 21 in "ext_tables.php" of "saltedpasswords".

Tomas, does moving those two lines into

if (tx_saltedpasswords_div::isUsageEnabled('BE')) {

Yes, Steffen, that works and thus it might be a correct fix. However, I'm unable to evaluate whether it fixes the right root of the problem. Someone should also confirm the bug in the first place as I have difficulty to believe that such a bug has been in a system extension without being noticed by anyone else.

Tomas, it looks pretty obvious, at least if saltedpasswords doesn't check in the User settings hook.

Will give it a try, but very likely at the end of the week after RC1 release.

Marcus Krause should have a look at that as well, I'll trigger him.

thanks for pointing me to this issue

Analysis:
Problems are obviously caused by following piece of code
$GLOBALS['TYPO3_USER_SETTINGS']['columns']['password']['eval'] = 'tx_saltedpasswords_eval_be';
$GLOBALS['TYPO3_USER_SETTINGS']['columns']['password2']['eval'] = '';

• default is 'md5'
• this triggers the md5 hash building of submitted password on clientside via JS
• it does not cause a real instanciation of an evaluation!!

with saltedpasswords installed and enabled, we only want a value for 'eval' key with anything else than 'md5'; having a class name like now is misleading!

• password is no longer md5 hashed via JS because TYPO3_USER_SETTINGS contains no 'md5'
• tcemains uses eval configured via TCA (=md5)
• submitted password (plain text) does not have the structure of an md5 hash (32 letter hexadecimal string)
• eval fails - no update!

• encapsulate (like already suggested) these files with a test if saltedpasswords is enabled for BE
• fix the misleading values / properly comment

I'll prepare a patch.

trunk rev. 10371
4.5 rev. 10372
4.4 rev. 10373
4.3 rev. 10374