Bug #99460
closed
Password recovery broken
0%
Description
When the forgot password function is used a exception pops up when the password is changed with the link from the recovery mail. The password change itself will work as the exception occurs afterwards. This happens since the latest TYPO3 update.
This is the error message:
Argument 1 passed to TYPO3\CMS\FrontendLogin\Controller\PasswordRecoveryController::invalidateUserSessions() must be of the type int, string given, called in /var/www/html/htdocs/typo3/sysext/felogin/Classes/Controller/PasswordRecoveryController.php on line 220
The $user array which is used in the method call contains a valid UID but it's a string and no integer.
Files
Updated by Torben Hansen almost 2 years ago
- File clipboard-202301061003-tcvz0.png clipboard-202301061003-tcvz0.png added
- Status changed from New to Needs Feedback
I was not able to reproduce the problem. The returned array with userdata is fetched from the database using doctrine and thus the types for columns(e.g. uid, pid, ...) are equal to the column data type in the database.
Can you please verify, that the field uid for the table fe_users is an integer in your database.
Updated by Hannes Bochmann almost 2 years ago
I thought that too but the uid column is indeed of type integer. Maybe some issue with the SQL mode (it's empty in my installation) but I couldn't find something in conjunction with Doctrine.
Updated by Torben Hansen over 1 year ago
Can you please provide additional information on how to exactly reproduce the problem.
Updated by Torben Hansen about 1 year ago
- Status changed from Needs Feedback to Closed
I'm closing this issue now, since it is not reproducible with currently supported TYPO3 versions and no feedback was provided. If the problem still persists for you in either TYPO3 11.5 or 12.4, please provide information on how to exactly reproduce the problem and I will re-open the issue.
Updated by Hannes Bochmann about 1 year ago
Sorry for the late response. I figured out what caused my problems. I use the PDO MySQL driver by setting $GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['url'] = 'mysql://...' and the PDO MySQL driver by default uses emulated prepared statements which cause this trouble. So I would need to set $GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['diverOptions'][\PDO::ATTR_EMULATE_PREPARES] = false; or switch to mysqli.
I see there is TYPO3\CMS\Core\Database\Driver\PDOMySql\Driver which would do that by default. But this driver is not used in my case. Is this because I use $GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['url'] and do not have $GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['driver'] configured? I haven't tested if it's the same behavior when I configure the database connection the "normal" way without the URL.